[clang][AArch64] Add --print-supported-extensions support #65466
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This follows the RISC-V work done in 4b40ced. 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.
github-actions
bot
added
the
clang:driver
|
I've generalised this a bit but mostly kept to what RISC-V did. If we think it's time to completely generalise it then I'll figure that out. Mostly want to know people are on board with supporting this for AArch64 first. |
DanielKristofKiss
approved these changes
Sep 7, 2023
ZijunZhaoCCK
pushed a commit
to ZijunZhaoCCK/llvm-project
that referenced
this pull request
Sep 19, 2023
This follows the RISC-V work done in 4b40ced. 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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This follows the RISC-V work done in 4b40ced.
This uses AArch64's target parser instead. We just list the names, without the "+" on them, which matches RISC-V's format.
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.