Page MenuHomePhabricator

Let clang print registered targets for --version
ClosedPublic

Authored by yaxunl on Thu, Apr 30, 2:51 PM.

Details

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.

Diff Detail

Event Timeline

yaxunl created this revision.Thu, Apr 30, 2:51 PM
tra added a subscriber: echristo.

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.

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?

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 added a comment.Fri, May 1, 2:33 PM

Is it OK to commit this? Thanks.

echristo accepted this revision.Fri, May 1, 4:07 PM

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.

This revision is now accepted and ready to land.Fri, May 1, 4:07 PM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptMon, May 4, 9:39 AM
hans added a subscriber: hans.Thu, May 7, 2:30 AM

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 added a comment.Thu, May 7, 4:26 AM

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

https://reviews.llvm.org/D79565

Thanks.

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?

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 added a comment.Thu, May 7, 7:58 AM

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.

@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 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