[RFC] Moving Target Info out of `--version` by default

As part of the work to move some parts of target-specific parsing out of Support, there’s a change I’d like to make people aware of that is related:

⚙ D137837 [Support] Move Target/CPU Printing out of CommandLine is the change in question

Right now, if you have configured cmake with LLVM_VERSION_PRINTER_SHOW_HOST_TARGET_INFO=On (The default), then most tools will print something like this when you invoke them as <tool> --version:

LLVM (http://llvm.org/):
  LLVM version 16.0.0git
  DEBUG build with assertions.
  Default target: x86_64-unknown-linux-gnu
  Host CPU: skylake-avx512

Often, this does not make sense, as the tools don’t actually do anything with the default target info and the host CPU info. For instance, llvm-dis/llvm-as/llvm-tblgen don’t as far as I can tell.

There are also cases where it is useful, because it gives you more information about e.g. the host a bug has been found on (if the report includes the version output!).

If my change is applied, then only tools which currently depend on llvm/Support/Host.h will print this information, and for other tools, the lines about Default target and Host CPU will not be printed (the preceding lines will be).

This information is easy to re-add after my patch, using the cl::AddExtraVersionPrinter(sys::printDefaultTargetAndDetectedCPU) code I’ve added to various utilities in that patch (where they were depending on Support/Host, or where the tests needed it to continue passing). This same mechanism is used to print the list of registered targets in llc and friends.

I’m keen to understand whether people are in favour of this change, or whether they will find it disruptive. There has been some discussion on the patch, so probably best to continue discussion there and for this thread to serve as a pointer to that discussion.

I’d hate to lose this from the flagship tools. If at least clang/lld/llc/opt printed the version, you could reasonably assume the other tools came from the same build. There’s no reason llvm-tblgen needs to have this

I just checked, with the proposed patch applied, all of these listed continue to do so. It seems clang uses its own mechanism for printing the current target, and I don’t think LLD currently prints the target / detected CPU anyway (I checked the output against my system install of lld-10 and it was the equivalent)

$ opt --version
LLVM (http://llvm.org/):
  LLVM version 16.0.0git
  DEBUG build with assertions.
  Default target: x86_64-unknown-linux-gnu
  Host CPU: skylake-avx512
$ llc --version
LLVM (http://llvm.org/):
  LLVM version 16.0.0git
  DEBUG build with assertions.
  Default target: x86_64-unknown-linux-gnu
  Host CPU: skylake-avx512

  Registered Targets:
    <snip>
$ clang --version
clang version 16.0.0
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /path/to/llvm-project/build/bin
$ ld.lld --version
LLD 16.0.0 (compatible with GNU linkers)

While reducing the dependencies on Host.h, we could add a new tool llvm-version that gives detailed information about the current LLVM including pointers where to report bugs.

I think we could do this, yes.

The intention of the work is to make everything in Support (in this particular case, CommandLine.cpp) not rely on Host.h or Triple.h. This absolutely does not mean that the tools we compile should not rely on Host.h or Triple.h.

Given I’m moving so much code around, I want to keep my patches closely scoped to moving code, but I’d be happy to review a follow-up for this new tool.

Thanks for creating the post! I think having the information in a few user-facing flagship applications (e.g. clang, flang; I won’t even bother lld) is sufficient, no need to duplicate in various tools called llvm-*.

1 Like

I think this is the consensus. My disposition is to land my patch linked above, if I get time tomorrow, so I can unblock @fpetrogalli’s work on the RISC-V target parser.

2 Likes

To follow up, the final version of my patch preserves printing the default target and CPU in the following tools. Clang uses a different mechanism for this info, and LLD and LLDB don’t print it at all right now.

  • opt
  • llc
  • llvm-mca
  • llvm-exegesis

I am planning to land the patch on Monday.

This landed in rG142aa1bdd1dd

2 Likes