This patch adds support for the PowerPC cryptography builtin functions to Clang. The support is meant to be gcc compatible as much as makes sense. The -m[no-]crypto option is added along with the corresponding predefined macro. The only place where this intentionally differs from gcc is that the option does not disable all of the builtins (only the ones that require Category:Vector.Crypto in the ISA document).
Diff Detail
- Repository
- rL LLVM
Event Timeline
Note to reviewers: There is currently no macro guard for the builtins that do not require Cagegory:Vector.Crypto. However, the back end will not generate code for them on older CPU's. Perhaps I should guard those with POWER8_VECTOR macro. However, this would imply that -mcrypto needs to imply -mpower8-vector which is probably the correct thing to do since Category:Vector.Crypto is a subset of Category:Vector.
I can make these changes and upload a revision if everyone agrees with this approach.
Because this is too big of a hammer. GCC made a mistake with this (I've proposed correcting this and will be working on fixing it in the future). We need to treat the SHA and AES support instructions as a separate group because Vector.Crypto is an optional implementation feature in the hardware, due to export control restrictions. POWER8 hardware with such instructions couldn't be transported legally to sensitive countries. But the other instructions in that section of the ISA are under no such legal restrictions, and as they are part of the Vector feature, they must be implemented for OpenPOWER-compliant implementations.
Understood. Exactly what have you proposed that GCC do?
My preference would be the following: Define intrinsics for these instructions without 'crypto' in the name, and make them available predicated only on POWER8_VECTOR. Define aliases (using #define or another inline function) to these with 'crypto' in the name, and have these available predicated on CRYPTO. This way the instructions remain generally available, but we don't end up in the confusing situation where __builtin_crypto_* functions are available even when the 'crypto' feature has been disabled.
In general, I agree with you. We have an open issue where GCC and the XL compilers have diverged in naming of the crypto builtins, and we need to get agreement on what the new names would be. Your proposal is a good place to start. We just haven't gotten around to cleaning that aspect up.
In the short term, I'd like to keep the same builtin names as GCC so we don't end up with 3 sets of names to reconcile, and to provide compatibility for any existing code that uses them. The existing names will be deprecated as soon as we can get new names in place, but I think we still need them to avoid compatibility issues in the near term.
Note that the __builtin_crypto_* forms of these instructions are documented in table A.3 (Optional Built-In Functions) of the ELF V2 ABI, so that's another reason to keep them for now.
(I believe we got in this situation because the Vector.Crypto designation was added very late in the POWER8 development cycle, after the binutils and builtin work for GCC was already done. The export restriction should have been caught much earlier, but wasn't.)
Alright. So, for now, add a POWER8_VECTOR guard around the non-crypto __builtin_crypto_* functions. Please also add a comment in the file noting the naming inconsistency, and stating that newer names are under development.
This update addresses the discussion regarding the macro guards in altivec.h. In order to maintain the same semantics for enabling/disabling the builtins as GCC has, there had to be some additional work. The comments in the code are hopefully descriptive enough, but here's a summary.
- GCC provides two ways to provide support for ALL of the builtins (-mcrypto and -mcpu=power8). We do the same now.
- Since some of the builtins are guarded by the POWER8_VECTOR macro, -mcrypto also enables the same semantics as -mpower8-vector
- It stands to reason that -mno-power8-vector should disable both sets (crypto and power8-vector builtins)
- However, -mno-crypto only disables the crypto builtins
- By default, -mcpu=power8 implies both
This only leaves us in a situation where -mcpu=pwr7 -mcrypto -mno-power8-vector actually leaves all the crypto builtins available. However, this would be a strange option set indeed.
Hi Nemanja,
Please see inline comment. The -mcrypto enablement is not quite right -- probably need to fix this up and resubmit. Sorry. :/
lib/Basic/Targets.cpp | ||
---|---|---|
981 | Mm, I don't want you to mimic current gcc behavior regarding -mcrypto. Current gcc behavior is wrong and must be brought into compliance. -mcrypto should turn on only the SHA and AES instructions (the same ones that -mno-crypto disables). Sorry if this was unclear, but we don't want to get into a confusing state where -mcrypto is not the opposite of -mno-crypto. |
LGTM with a few small changes noted inline.
lib/CodeGen/CGBuiltin.cpp | ||
---|---|---|
6354 | This code should be predicated on the crypto feature being enabled. It is possible for someone to use llc with -mattr=-crypto and specify these builtins. We need to fail gracefully when that happens. Kit just did something similar so you can check with him if you have questions. | |
lib/Headers/altivec.h | ||
12665 | Change the FIXME here to a NOTE, as this is GCC's problem, not LLVM's. | |
12676 | You can put a FIXME on this specific part. |
Mm, I don't want you to mimic current gcc behavior regarding -mcrypto. Current gcc behavior is wrong and must be brought into compliance. -mcrypto should turn on only the SHA and AES instructions (the same ones that -mno-crypto disables). Sorry if this was unclear, but we don't want to get into a confusing state where -mcrypto is not the opposite of -mno-crypto.