Skip to content
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

AArch64: Mismatch between compiler features and runtime detection #1432

Open
Amanieu opened this issue May 25, 2023 · 1 comment
Open

AArch64: Mismatch between compiler features and runtime detection #1432

Amanieu opened this issue May 25, 2023 · 1 comment

Comments

@Amanieu
Copy link
Member

Amanieu commented May 25, 2023

While reviewing the list of target features, I noticed 2 inconsistencies between the list used by the compiler and the one used by stdarch for runtime feature detection.

Specifically these features are present as a separate feature in the runtime detection list but are folded into another feature in the compiler:

  • fp can be detected at runtime but can't be enabled. It is instead implied by the neon feature.
  • pmull can be detected at runtime but can't be enabled. It is instead implied by the aes feature, and all the related intrinsics use the aes target feature.

cc @JamieCunliffe @adamgemmell @workingjubilee

@adamgemmell
Copy link
Contributor

On fp, I believe this was intentional, though it wasn't discussed deeply. This is because we judged that an OS could expose what it likes between the two (linux exposes separate bits for the two). This went a bit deeper in #1311 where I note that the two lists are now logically separate and allow for a mapping from runtime to compiler features. Maybe the question should be "is there a use for detecting fp at runtime without checking for neon?" We also can't remove the fp runtime feature at this point since it's stable. About the only thing I can think of that we can do is to make both runtime features query fp && neon, but I'm not sure what exactly that solves.

I think that question also applies regarding detecting pmull without checking for aes. If nothing else, I thing we should add FEAT_PMULL to the aes target_feature here and link the runtime feature to the aes target_feature.

I should probably also say that there's been no further sign that we can simplify target_features beyond merging fp into neon. This makes that situation more of an outlier than a simplification.

GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue Feb 15, 2024
…target-features, r=Amanieu

Update aarch64 target feature docs to match LLVM

rust-lang/stdarch#1432 rust-lang/stdarch#1527

r? `@Amanieu`
oli-obk added a commit to oli-obk/rust that referenced this issue Feb 15, 2024
…target-features, r=Amanieu

Update aarch64 target feature docs to match LLVM

rust-lang/stdarch#1432 rust-lang/stdarch#1527

r? ``@Amanieu``
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue Feb 15, 2024
…target-features, r=Amanieu

Update aarch64 target feature docs to match LLVM

rust-lang/stdarch#1432 rust-lang/stdarch#1527

r? ```@Amanieu```
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Feb 16, 2024
Rollup merge of rust-lang#121145 - adamgemmell:dev/adagem01/combined-target-features, r=Amanieu

Update aarch64 target feature docs to match LLVM

rust-lang/stdarch#1432 rust-lang/stdarch#1527

r? ```@Amanieu```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants