[all-commits] [llvm/llvm-project] 90db41: [clang][AArch64] Add --print-supported-extensions ...

[David Spickett via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 90db4193f82937bff68c8f8a1481320f245f04ff
      https://github.com/llvm/llvm-project/commit/90db4193f82937bff68c8f8a1481320f245f04ff
  Author: David Spickett <david.spickett at linaro.org>
  Date:   2023-09-11 (Mon, 11 Sep 2023)

  Changed paths:
    M clang/include/clang/Driver/Options.td
    M clang/lib/Driver/Driver.cpp
    A clang/test/Driver/print-supported-extensions.c
    M clang/tools/driver/cc1_main.cpp
    M llvm/include/llvm/TargetParser/AArch64TargetParser.h
    M llvm/lib/TargetParser/AArch64TargetParser.cpp
    M llvm/unittests/TargetParser/TargetParserTest.cpp

  Log Message:
  -----------
  [clang][AArch64] Add --print-supported-extensions support (#65466)

This follows the RISC-V work done in
4b40ced4e5ba10b841516b3970e7699ba8ded572.

This uses AArch64's target parser instead. We just list the names,
without the "+" on them, which matches RISC-V's format.

```
$ ./bin/clang -target aarch64-linux-gnu --print-supported-extensions
clang version 18.0.0 (https://github.com/llvm/llvm-project.git 154da8aec20719c82235a6957aa6e461f5a5e030)
Target: aarch64-unknown-linux-gnu
Thread model: posix
InstalledDir: <...>
All available -march extensions for AArch64

        aes
        b16b16
        bf16
        brbe
        crc
        crypto
        cssc
        <...>
```

Since our extensions don't have versions in the same way there's just
one column with the name in.

Any extension without a feature name (including the special "none") is
not listed as those cannot be passed to -march, they're just for the
backend. For example the MTE extension can be added with "+memtag" but
MTE2 and MTE3 do not have feature names so they cannot be added to
-march.

This does not attempt to tackle the fact that clang allows invalid
combinations of AArch64 extensions, it simply lists the possible
options. It's still up to the user to ask for something sensible.

Equally, this has no context of what CPU is being selected. Neither does
the RISC-V option, the user has to be aware of that.

I've added a target parser test, and a high level clang test that checks
RISC-V and AArch64 work and that Intel, that doesn't support this, shows
the correct error.