Let clang print registered targets for --version

[yaxunl]

Summary

We need a way to know supported targets by clang since we use clang as assembler.

This patch let clang print registered targets when --version option is passed to clang.

[tra]

LGTM, I've been annoyed by the lack of this info in the past.
I've added @echristo for the driver owner's stamp of approval.

[echristo]

LGTM if it works? Can you post the output into the commit message so we can review that here? I guess clang -v or something?

[yaxunl]

A sample output:

clang --version
clang version 11.0.0 (https://github.com/llvm/llvm-project d0a30964c78cec2e3907be8ec16cfbec69bc3f2d)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/yaxunl/git/llvm/assert/bin

Registered Targets:
  aarch64    - AArch64 (little endian)
  aarch64_32 - AArch64 (little endian ILP32)
  aarch64_be - AArch64 (big endian)
  amdgcn     - AMD GCN GPUs
  arm        - ARM
  arm64      - ARM64 (little endian)
  arm64_32   - ARM64 (little endian ILP32)
  armeb      - ARM (big endian)
  avr        - Atmel AVR Microcontroller
  bpf        - BPF (host endian)
  bpfeb      - BPF (big endian)
  bpfel      - BPF (little endian)
  hexagon    - Hexagon
  lanai      - Lanai
  mips       - MIPS (32-bit big endian)
  mips64     - MIPS (64-bit big endian)
  mips64el   - MIPS (64-bit little endian)
  mipsel     - MIPS (32-bit little endian)
  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)
  wasm32     - WebAssembly 32-bit
  wasm64     - WebAssembly 64-bit
  x86        - 32-bit X86: Pentium-Pro and above
  x86-64     - 64-bit X86: EM64T and AMD64
  xcore      - XCore

[yaxunl]

Is it OK to commit this? Thanks.

[echristo]

Yeah, it's fine. We might want to put it behind a "long information" option, but for now it's ok. Keep an eye open if someone complains please.

[hans]

I think this is worth a short note in docs/ReleaseNotes.rst.

Also this broke Goma which we use in Chromium (https://chromium.googlesource.com/infra/goma/client/) because it's a bit too strict when parsing the output of "clang -v" -- but that's our problem and we'll fix. :-)

[yaxunl]

In D79210#2024555, @hans wrote:

I think this is worth a short note in docs/ReleaseNotes.rst.

https://reviews.llvm.org/D79565

Thanks.

[thakis]

We've talked about this 3 years ago in https://reviews.llvm.org/D33900 and back then decided that this should go behind a different flag. Has anything changed since then?

[thakis]

In D79210#2025009, @thakis wrote:

We've talked about this 3 years ago in https://reviews.llvm.org/D33900 and back then decided that this should go behind a different flag. Has anything changed since then?

To expand a bit:

• Listing targets under --version doesn't make obvious sense semantically; a different --print-target flags would make more sense
• Several tools parse --version / -v output, so adding it there might break them

From the description it sounds like a separate flag for this would work for you, so I'd say we revert this and reland it under a different flag. Does that make sense?

[yaxunl]

In D79210#2025058, @thakis wrote:

In D79210#2025009, @thakis wrote:

We've talked about this 3 years ago in https://reviews.llvm.org/D33900 and back then decided that this should go behind a different flag. Has anything changed since then?

To expand a bit:

• Listing targets under --version doesn't make obvious sense semantically; a different --print-target flags would make more sense
• Several tools parse --version / -v output, so adding it there might break them

From the description it sounds like a separate flag for this would work for you, so I'd say we revert this and reland it under a different flag. Does that make sense?

I am not aware of the previous discussion. I will revert it and reland it under --print-target.

[thakis]

Thanks!

[MaskRay]

@yaxunl The plural form --print-targets may make more sense to be consistent with other plural form options (--print-search-dirs, --print-diagnostic-categories, etc)

[yaxunl]

In D79210#2025547, @MaskRay wrote:

@yaxunl The plural form --print-targets may make more sense to be consistent with other plural form options (--print-search-dirs, --print-diagnostic-categories, etc)

Agree

clang/lib/Driver/Driver.cpp

void Driver::PrintVersion(const Compilation &C, raw_ostream &OS) const {
   OS << '\n';
 
   // Print out the install directory.
   OS << "InstalledDir: " << InstalledDir << '\n';
 
   // If configuration file was used, print its path.
   if (!ConfigFile.empty())
     OS << "Configuration file: " << ConfigFile << '\n';
+
+  // Print the registered targets.
+  llvm::TargetRegistry::printRegisteredTargetsForVersion(OS);
 }
 
 /// PrintDiagnosticCategories - Implement the --print-diagnostic-categories
 /// option.
 static void PrintDiagnosticCategories(raw_ostream &OS) {
   // Skip the empty category.
   for (unsigned i = 1, max = DiagnosticIDs::getNumberOfCategories(); i != max;
        ++i)