Page MenuHomePhabricator

Add Clang support for PPC cryptography builtins
ClosedPublic

Authored by nemanjai on Feb 27 2015, 11:48 AM.

Details

Summary

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

nemanjai updated this revision to Diff 20873.Feb 27 2015, 11:48 AM
nemanjai retitled this revision from to Add Clang support for PPC cryptography builtins.
nemanjai updated this object.
nemanjai edited the test plan for this revision. (Show Details)
nemanjai set the repository for this revision to rL LLVM.
nemanjai added a subscriber: Unknown Object (MLST).

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.

hfinkel edited edge metadata.Feb 27 2015, 12:09 PM

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.

Why don't we guard them all with CRYPTO? It seems somewhat odd to have some, but not all, of the __builtin_crypto_* available when the crypto feature is disabled.

lib/CodeGen/CGBuiltin.cpp
6362

Line too long?

6366

Line too long?

wschmidt edited edge metadata.Feb 27 2015, 12:25 PM

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.

Why don't we guard them all with CRYPTO? It seems somewhat odd to have some, but not all, of the __builtin_crypto_* available when the crypto feature is disabled.

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.

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.

Why don't we guard them all with CRYPTO? It seems somewhat odd to have some, but not all, of the __builtin_crypto_* available when the crypto feature is disabled.

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.

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.

Why don't we guard them all with CRYPTO? It seems somewhat odd to have some, but not all, of the __builtin_crypto_* available when the crypto feature is disabled.

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.)

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.

Why don't we guard them all with CRYPTO? It seems somewhat odd to have some, but not all, of the __builtin_crypto_* available when the crypto feature is disabled.

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.

nemanjai updated this revision to Diff 21018.Mar 2 2015, 11:11 AM
nemanjai edited edge metadata.

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.

nemanjai updated this revision to Diff 21078.Mar 2 2015, 9:12 PM

Simplified the logic to address Bill Schmidt's comment about -mcrypto.

wschmidt accepted this revision.Mar 3 2015, 8:05 AM
wschmidt edited edge metadata.

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.

This revision is now accepted and ready to land.Mar 3 2015, 8:05 AM
nemanjai closed this revision.Mar 4 2015, 1:54 PM

Committed revision 231291.