-
Notifications
You must be signed in to change notification settings - Fork 130
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cpufeatures: incongruities between ARM64 hwcaps and Rust SHA* target features #395
Comments
I think the short answer to my question is "yes". In the Likewise it would be nice to support the From what I can tell There are also quite a number of additional target features which would benefit the performance of AES implementations. Notably:
|
Closes #395 The HWCAPs provided by Linux are finer-grained than LLVM target features. This crate is trying to detect the latter, so we need to group together these finer grained features detected via HWCAPs. This commit attempts to group together finer grained HWCAPs into coarser grained target features, ensuring all of the relevant HWCAPs for a given target feature are available. Additionally, this adds support for the `crypto` target feature, which implies `aes` (and with it PMULL), along with `sha2` and `neon` (although the latter is always present on `aarch64`)
) Closes #395 The HWCAPs provided by Linux are finer-grained than LLVM target features. This crate is trying to detect the latter, so we need to group together these finer grained features detected via HWCAPs. This commit attempts to group together finer grained HWCAPs into coarser grained target features, ensuring all of the relevant HWCAPs for a given target feature are available. Additionally, this adds support for the `crypto` target feature, which implies `aes` (and with it PMULL), along with `sha2` and `neon` (although the latter is always present on `aarch64`)
Do you know how Rust toolchain currently handles those features?A bit while ago when I looked into it, I think it had only a general |
From what I've gathered, Rust target features map directly to the corresponding LLVM ones.
Yeah, unfortunately I didn't include citations for the mappings. I really should've, my bad. But indeed I saw it gets quite tricky. Here's some info I found via a cursory googling: https://lists.llvm.org/pipermail/llvm-dev/2018-September/126346.html On AArch64,
Given only the Also note that only |
I think I've seen somewhere a suggestion in the LLVM mailing list to split the I really hope that Rust eventually will adopt separate ( |
Following up from #393:
The output of
rustc --target=aarch64-unknown-linux-gnu --print target-features
shows the following cryptography-related target features on ARM64 (which is the same foraarch64-apple-darwin
)This suggests that
sha2
implies SHA-1 support, and thatsha3
implies SHA(2)-512 support (but curiously, that the aforementionedsha2
does not).This does not consistent with the Linux hwcaps or the ARM registers they map to (or for that matter, the algorithm families the respective algorithms belong to):
https://www.kernel.org/doc/html/latest/arm64/elf_hwcaps.html
On macOS targets, support for
sha1
andsha2
is implicit, however support for SHA-512 and SHA-3 intrinsics can be queried throughsysctl(3)
.Question:
How should
cpufeatures
handle this mapping? For example, should checking for support for thesha3
target feature usingcpufeatures
test for support for both SHA(2)-512 and SHA-3, and return false unless both are available?Sidebar: do the Rust target feature mappings actually make sense here? Should
sha3
perhaps be decoupled from SHA(2)-512?The text was updated successfully, but these errors were encountered: