This adds some basic handling for target("+crypto") attributes. In this patch it just enabled aes and sha2 regardless of the architecture revision, which matches gccs implementation (and keeps this patch simple).
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I'm concerned that the +crypto situation is already confusing, and adding another different meaning for it in the context of the target(...) attribute exacerbates it. Is the plan for this to eventually match the behaviour of -march=...+crypto?
Yeah - Considering that GCC has not implemented armv8.4-a+crypto implying +sha3 and +sm4, we either have the option of matching the behavior of GCC's target("+crypto"), or being more consistent with clang's -march=.... With a number of CPU's being released which implement SHA3 but not SM4, the simpler GCC implementation might be the better way to go to be honest, and we could consider changing how -march works in clang to match.
If you feel strongly I can have a go at implementing it to be arch dependent. Let me know.
By the way I don't really have any more to add, and I've lost track of what the status of +crypto is after all the recent changes, so don't let me block this. From what you've said aligning with GCC sounds sensible, but an intermediate stage where -march does one thing and the target attribute does another seems less ideal.
OK - I think it is worth going forward with this patch so that +crypto at least does something sensible. Otherwise we will get errors like https://github.com/llvm/llvm-project/issues/61645. We can then sort out +crypto at a later point
Ping. I would like to get this into the release so that it isn't quite so broken as it is now. Otherwise +crypto does not do anything for target attributes, and I would like to avoid needing more and more ifdefs based on compiler versions to get correct.