cpufeatures: aarch64 support (Linux and macOS/M4) #393
Conversation
| ("aes", HWCAP_AES), // Enable AES support. | ||
| ("sha2", HWCAP_SHA2), // Enable SHA1 and SHA256 support. | ||
| ("sha3", HWCAP_SHA3), // Enable SHA512 and SHA3 support. |
There was a problem hiding this comment.
Note: the comments here are taken directly from the output of:
$ rustc --target=aarch64-unknown-linux-gnu --print target-features
The output for these target features is the same on an aarch64-apple-darwin target.
I'm a bit confused because the target features aren't isomorphic to either the Linux ARM64 ELF hwcaps or the macOS sysctl flags.
Per the Linux ARM64 ELF hwcaps docs:
https://www.kernel.org/doc/html/latest/arm64/elf_hwcaps.html
HWCAP_SHA1: Functionality implied by ID_AA64ISAR0_EL1.SHA1 == 0b0001.
HWCAP_SHA2: Functionality implied by ID_AA64ISAR0_EL1.SHA2 == 0b0001.
HWCAP_SHA3: Functionality implied by ID_AA64ISAR0_EL1.SHA3 == 0b0001.
HWCAP_SHA512: Functionality implied by ID_AA64ISAR0_EL1.SHA2 == 0b0010.
That would suggest that the SHA-1 and SHA-3 hwcaps are independent of the others, and that SHA-2 support implies SHA-512 support.
macOS/M4 likewise has separate sysctl(3) flags for SHA-512 and SHA-3:
hw.optional.armv8_2_sha512: 1
hw.optional.armv8_2_sha3: 1
...but the rustc target-features suggest that sha2 implies SHA-1 support, and that sha3 implies SHA-512 support.
tarcieri
force-pushed
the
cpufeatures/aarch64
branch
4 times, most recently
from
16e4ecf to
6515a6b
Compare
tarcieri
changed the title
tarcieri
force-pushed
the
cpufeatures/aarch64
branch
6 times, most recently
from
59b29d6 to
cfbcd7e
Compare
tarcieri
changed the title
Adds preliminary support for runtime feature detection on `aarch64` targets, presently restricted to the following set of target features which are present on both `aarch64-unknown-linux-gnu` and `aarch64-apple-darwin` targets: - `aes`: AES support - `sha2`: SHA1 and SHA256 support - `sha3`: SHA512 and SHA3 support
tarcieri
force-pushed
the
cpufeatures/aarch64
branch
from
cfbcd7e to
6efb380
Compare
|
Marking this as ready for review. I was able to extract the CPU-specific bits from the Linux and MacOS targets now work on AFAICT this is not a breaking change and should be fully compatible with the existing v0.1.0 release. I think the biggest remaining question is my earlier comment about how Rust's ARM64 target features don't seem to fully align with Linux HWCAPs or MacOS armcaps, though the OS-level strategies seem consistent with each other as well as the ARM capability registers. Not sure what to do about that but if anything is wrong, it seems to be Rust's own target feature mapping as everything else (ARM64 docs, Linux, and macOS) are all consistent with each other. @newpavlov mind taking a look? |
| #[macro_export] | ||
| #[doc(hidden)] | ||
| macro_rules! __unless_target_features { | ||
| ($($tf:tt),+ => $body:expr ) => { |
There was a problem hiding this comment.
Played around with a few different syntaxes for this macro and this is the best one I could come up with.
Open to suggestions for alternatives.
|
I'll move my concerns about the mappings of ARM CPU features Rust target features to a separate issue (edit: opened #395).
Edit: okay, going to go ahead and ship a v0.1.1, but I won't ship any crates that depend on it. Everything that depends on it now only uses the x86/x86-64 support which should be unchanged by this PR. If need be we can make breaking changes to the ARM backend. |
Adds preliminary support for runtime feature detection on
aarch64targets, presently restricted to the following set of target features which are present on bothaarch64-unknown-linux-gnuandaarch64-apple-darwintargets:aes: AES supportsha2: SHA1 and SHA256 supportsha3: SHA512 and SHA3 supportCloses #378