Remove the aes feature from many arm intrinsics

[adamgemmell]

Fixes #2109

The aes rust feature represents FEAT_AES and FEAT_PMULL - from the architecture reference manual, these just add 4 new aes* instructions, and the p64 variants of PMULL/PMULL2.

Clang's header doesn't seem to gate any poly types on the aes feature, and many of the intrinsics with the aes feature are nops or just load/stores, for which the aes feature shouldn't matter. Accordingly, I've removed the aes feature from all intrinsics except the vaes* intrinsics, and ones using the p64 variants of PMULL[2] instructions

[rustbot]

r? @folkertdev

rustbot has assigned @folkertdev.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @Amanieu, @folkertdev, @sayantn
• @Amanieu, @folkertdev, @sayantn expanded to Amanieu, folkertdev, sayantn
• Random selection from Amanieu, folkertdev, sayantn

[folkertdev]

This changes public, stable signatures. I don't think it can be observed (it's just removing a constraint), but we should be careful.

Is there any way to validate that the new versions in fact work? I suspect that our CI just has the aes feature available anyway, so if any of these functions did still generate an aes instruction we'd not notice. Maybe qemu can be configured to just have neon, and not aes locally?

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[adamgemmell]

This changes public, stable signatures. I don't think it can be observed (it's just removing a constraint), but we should be careful.

A few cases I can think of where removing a target feature could cause a breaking change:

• It's an evil one that changes the ABI - aes is a pretty simple one that just allows the generation of some instruction variants.
• It changes inlining behaviour - not technically breaking, but annoying, particularly with simd intrinsics. With the AArch64/ARM LLVM backends in particular, I expect that removing this feature will just allow the function to be inlined into more contexts rather than fewer.
• Having to revert this patch, of course, could be disruptive if required.

Is there any way to validate that the new versions in fact work? I suspect that our CI just has the aes feature available anyway, so if any of these functions did still generate an aes instruction we'd not notice. Maybe qemu can be configured to just have neon, and not aes locally?

I did test this locally with some qemu cpus that don't support the crypto extension and it worked. I wanted to push it to CI to demonstrate it working but it's quite annoying to do so

If we rely on LLVM, it will fail to generate any instructions that require the aes feature when it's not available. intrinsic-test does not put target features on its test wrappers nor build with -Ctarget-feature, so those intrinics are running without the aes feature present.

Also, sayantn's concern at #2109 (comment) regarding GCC isn't fully resolved yet