This patch enhances Clang flags -mcrypto and -mno-crypto to enable/disable crypto feature.
Before this change, -m(no-)crypto is exclusively for Power8. We want to add this feature
to ARM/AArch64 as well. With -mcrypto is specified, '+crypto' will be passed as
a target feature to ARM/AArch64/Power8, and -mno-cypto will remove target feature '-crypto'.
Details
- Reviewers
kristof.beyls dlj manojgupta peter.smith
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 30259 Build 30258: arc lint + arc unit
Event Timeline
clang/include/clang/Driver/Options.td | ||
---|---|---|
2218 | Can you move it out of ppc specific options area to more generic options location e.g. like hard-float? | |
2219 | ARM/AArch64/PowerPC | |
2221 | ARM/AArch64/PowerPC | |
clang/lib/Driver/ToolChains/Arch/AArch64.cpp | ||
192 | I believe this should be merged with the code for OPT_mgeneral_regs_only otherwise the next if statement for mgeneral-regs-only would force "-crypto" . if (A->getOption().matches(OPT_mgeneral_regs_only))) Please also add tests when mgeneral-regs-only is specified with "-mcrypto" before/after. | |
clang/lib/Driver/ToolChains/Arch/ARM.cpp | ||
453 | Please add a test for interaction with soft-float ABI option. |
clang/lib/Driver/ToolChains/Arch/AArch64.cpp | ||
---|---|---|
192 | Understand. My question of the logic is that if -mgeneral-regs-only comes before -mcrypto, do we want to set "-fp-armv8" "-neon" or not? In other words, if -mcrypto comes after -mgeneral-regs-only, does it only override '+crypto' or override all the three features? I'll change the logic and add tests after making sure what we really want to do. |
What's the motivation for this change, are you working towards common flags for both platforms? The current way to select crypto on AArch64 is '-march=armv8.x-a+crypto/nocrypto'. I can see that would be an issue if Power PC doesn't support that syntax, or doesn't have a specific crypto extension.
I'm not in favour of adding AArch64 support to -mcrypto -mnocrypto for a few reasons:
- Arm are trying to keep the options for controlling target features as consistent as possible with GCC and this option isn't supported in GCC (https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html)
- There is http://lists.llvm.org/pipermail/llvm-dev/2018-September/126346.html which is Arm's proposal for how target options can be better supported in Clang. I think that supporting -mcrypto as well would add more complexity as there are interactions between the options.
- Arm 32-bit also supports crypto so this would need to be added to Arm as well for consistency.
Can you expand on why you need -m[no]crypto?
The motivation for this change is to make "crypto" setting an additive option e.g. like "-mavx" used in many media packages. Some packages in Chrome want to enable crypto conditionally for a few files to allow crypto feature to be used based on runtime cpu detection. They set "-march=armv8+crypto" flag but it gets overridden by the global "-march=armv8a" flag set by the build system in Chrome OS because the target cpu does not support crypto causing compile-time errors.
Ability to specify "-mcrypto" standalone makes it an additive option and ensures that it it is not lost. i.e. this will help in decoupling "-mcrypto" from "-march" so that they could be set independently. The current additive alternate is '-Xclang -target-feature -Xclang "+crypto" ' which is ugly.
Is that not a limitation of the build system? I'd expect a package to be able to locally override a global default rather than vice-versa. Although crypto might be the area of concern here and there may be a conveniently named option for PPC, where does this stop? Crypto is not the only architectural extension, for example see https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html . To maintain a consistent interface we'd need command line options for all the extensions. May I encourage you to reply to the RFC on command line options that I mentioned earlier if it doesn't work for you? I think the extensions need to be considered as a whole and not just individually.
Is that not a limitation of the build system? I'd expect a package to be able to locally override a global default rather than vice-versa. Although crypto might be the area of concern here and there may be a conveniently named option for PPC, where does this stop? Crypto is not the only architectural extension, for example see https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html . To maintain a consistent interface we'd need command line options for all the extensions. May I encourage you to reply to the RFC on command line options that I mentioned earlier if it doesn't work for you? I think the extensions need to be considered as a whole and not just individually.
While it partly is a build system issue, another problem is enabling crypto via "-march" requires picking an architecture as well. So even if it could override the global default, it would also override the global "-march" as well. If the global "-march" was a better/higher option, it does not make sense to override it e.g. "-march=armv8-a+crypto" overriding "-march=armv8.3-a" is not helpful since it will disable 8.3 features.
Is that not a limitation of the build system? I'd expect a package to be able to locally override a global default rather than vice-versa. Although crypto might be the area of concern here and there may be a conveniently named option for PPC, where does this stop? Crypto is not the only architectural extension, for example see https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html . To maintain a consistent interface we'd need command line options for all the extensions. May I encourage you to reply to the RFC on command line options that I mentioned earlier if it doesn't work for you? I think the extensions need to be considered as a whole and not just individually.
I'll also read the RFC and respond.
Can you move it out of ppc specific options area to more generic options location e.g. like hard-float?