This is an archive of the discontinued LLVM Phabricator instance.

Print registered targets in clang's version information
ClosedPublic

Authored by dim on Jun 5 2017, 9:54 AM.

Details

Summary

Other llvm tools display their registered targets when showing version
information, but for some reason clang has never done this.

To support this, D33899 adds the llvm parts, which make it possible to
print version information to arbitrary raw_ostreams. This change adds
a call to printRegisteredTargetsForVersion in clang's PrintVersion, and
adds a raw_ostream parameter to two other PrintVersion functions.

Event Timeline

dim created this revision.Jun 5 2017, 9:54 AM
This revision is now accepted and ready to land.Jun 6 2017, 2:30 PM
dim closed this revision.Jun 6 2017, 2:54 PM
thakis added a subscriber: thakis.Jul 24 2017, 8:36 AM

Sorry, I just noticed this weeks later. Why are we adding this to --version instead of adding some new flag for printing this? When I pass --version, I'm usually interested in clang's version and don't need a screenful of other information below it (which makes the output I do care about scroll off the screen).

Here is the current output:

clang version 5.0.0 
Target: x86_64-apple-darwin16.6.0
Thread model: posix
InstalledDir: /Users/mamini/projects/llvm/./clangDebug/bin

  Registered Targets:
    aarch64    - AArch64 (little endian)
    aarch64_be - AArch64 (big endian)
    amdgcn     - AMD GCN GPUs
    arm        - ARM
    arm64      - ARM64 (little endian)
    armeb      - ARM (big endian)
    bpf        - BPF (host endian)
    bpfeb      - BPF (big endian)
    bpfel      - BPF (little endian)
    hexagon    - Hexagon
    lanai      - Lanai
    mips       - Mips
    mips64     - Mips64 [experimental]
    mips64el   - Mips64el [experimental]
    mipsel     - Mipsel
    msp430     - MSP430 [experimental]
    nvptx      - NVIDIA PTX 32-bit
    nvptx64    - NVIDIA PTX 64-bit
    ppc32      - PowerPC 32
    ppc64      - PowerPC 64
    ppc64le    - PowerPC 64 LE
    r600       - AMD GPUs HD2XXX-HD6XXX
    riscv32    - 32-bit RISC-V
    riscv64    - 64-bit RISC-V
    sparc      - Sparc
    sparcel    - Sparc LE
    sparcv9    - Sparc V9
    systemz    - SystemZ
    thumb      - Thumb
    thumbeb    - Thumb (big endian)
    x86        - 32-bit X86: Pentium-Pro and above
    x86-64     - 64-bit X86: EM64T and AMD64
    xcore      - XCore

I think @thakis is right: this too verbose to be the default --version.
We likely shouldn't ship this in clang-5.0 (@hans).

dim added a comment.Jul 24 2017, 12:04 PM

Sorry, I just noticed this weeks later. Why are we adding this to --version instead of adding some new flag for printing this? When I pass --version, I'm usually interested in clang's version and don't need a screenful of other information below it (which makes the output I do care about scroll off the screen).

I added it there, for consistency with other LLVM tools, for example:

$ llc -version
LLVM (http://llvm.org/):
  LLVM version 5.0.0svn-r308421
  Optimized build with assertions.
  Default target: x86_64-unknown-freebsd12.0
  Host CPU: ivybridge

  Registered Targets:
    aarch64    - AArch64 (little endian)
    aarch64_be - AArch64 (big endian)
    arm        - ARM
    arm64      - ARM64 (little endian)
    armeb      - ARM (big endian)
    mips       - Mips
    mips64     - Mips64 [experimental]
    mips64el   - Mips64el [experimental]
    mipsel     - Mipsel
    ppc32      - PowerPC 32
    ppc64      - PowerPC 64
    ppc64le    - PowerPC 64 LE
    sparc      - Sparc
    sparcel    - Sparc LE
    sparcv9    - Sparc V9
    thumb      - Thumb
    thumbeb    - Thumb (big endian)
    x86        - 32-bit X86: Pentium-Pro and above
    x86-64     - 64-bit X86: EM64T and AMD64
$ llvm-mc -version
LLVM (http://llvm.org/):
  LLVM version 5.0.0svn-r308421
  Optimized build with assertions.
  Default target: x86_64-unknown-freebsd12.0
  Host CPU: ivybridge

  Registered Targets:
    aarch64    - AArch64 (little endian)
    aarch64_be - AArch64 (big endian)
    arm        - ARM
    arm64      - ARM64 (little endian)
    armeb      - ARM (big endian)
    mips       - Mips
    mips64     - Mips64 [experimental]
    mips64el   - Mips64el [experimental]
    mipsel     - Mipsel
    ppc32      - PowerPC 32
    ppc64      - PowerPC 64
    ppc64le    - PowerPC 64 LE
    sparc      - Sparc
    sparcel    - Sparc LE
    sparcv9    - Sparc V9
    thumb      - Thumb
    thumbeb    - Thumb (big endian)
    x86        - 32-bit X86: Pentium-Pro and above
    x86-64     - 64-bit X86: EM64T and AMD64

etc. I'm fine with a separate flag for clang, but it would be nice if the other LLVM tools used the same flag.

dim added a comment.Jul 24 2017, 12:06 PM

Also note that it is only added to the --version output, not the -v output (the former is really a "verbose" version of the latter):

$ clang -v
clang version 5.0.0 (trunk 308421)
Target: x86_64-unknown-freebsd12.0
Thread model: posix
InstalledDir: /share/dim/llvm/308421-trunk-freebsd12-amd64-ninja-rel-1/bin
In D33900#819234, @dim wrote:

Sorry, I just noticed this weeks later. Why are we adding this to --version instead of adding some new flag for printing this? When I pass --version, I'm usually interested in clang's version and don't need a screenful of other information below it (which makes the output I do care about scroll off the screen).

I added it there, for consistency with other LLVM tools, for example:

I think most of the LLVM tools are kind of internal to LLVM and only used by people working on LLVM. clang on the other hand is used primarily by people not working on LLVM. We usually try to keep --version output for tools that are primarily used by non-LLVM devs concise, see e.g. http://llvm.org/viewvc/llvm-project?rev=198694&view=rev

hans edited edge metadata.Jul 25 2017, 9:32 AM
In D33900#819237, @dim wrote:

Also note that it is only added to the --version output, not the -v output (the former is really a "verbose" version of the latter):

Which seems to be the opposite of what gcc does (gcc -v is more verbose than gcc --version.)

$ gcc --version
gcc (GCC) 4.9.0 20140318 (experimental)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/google/work/gcc482prefix/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/work/gcc482prefix --enable-languages=c,c++ --enable-checking=release
Thread model: posix
gcc version 4.9.0 20140318 (experimental) (GCC)

I think @thakis is right: this too verbose to be the default --version.
We likely shouldn't ship this in clang-5.0 (@hans).

Let me know if you figure out a solution here and I'll merge it.

In D33900#820281, @hans wrote:

I think @thakis is right: this too verbose to be the default --version.
We likely shouldn't ship this in clang-5.0 (@hans).

Let me know if you figure out a solution here and I'll merge it.

I looped you in because the easy short term answer is: that we take our time to figure what to do in trunk but in the meantime we just revert from the release branch.

hans added a comment.Jul 27 2017, 9:23 AM
In D33900#820281, @hans wrote:

I think @thakis is right: this too verbose to be the default --version.
We likely shouldn't ship this in clang-5.0 (@hans).

Let me know if you figure out a solution here and I'll merge it.

I looped you in because the easy short term answer is: that we take our time to figure what to do in trunk but in the meantime we just revert from the release branch.

Makes sense. I've reverted r304899 and r304836 in r309285, and r304835 in r309286.

dim: Does putting the target listing behind a different flag work for you? Which problem are you trying to solve here?

dim added a comment.Jul 28 2017, 10:36 AM

dim: Does putting the target listing behind a different flag work for you? Which problem are you trying to solve here?

I'm fine with a different flag. For the problem I was trying to solve, see my earlier comments, e.g. I wanted to 1) know what the compiled-in targets were and 2) achieve consistency with the other LLVM tools.

thakis added a comment.Aug 3 2017, 9:47 AM

I've reverted this in 309960, as discussed.