Repository navigation
AArch64: Mismatch between compiler features and runtime detection #1432
Description
Activity
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 detectingfpat runtime without checking forneon?" We also can't remove thefpruntime 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 queryfp && neon, but I'm not sure what exactly that solves.I think that question also applies regarding detecting
pmullwithout checking foraes. If nothing else, I thing we should addFEAT_PMULLto theaestarget_feature here and link the runtime feature to theaestarget_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.
- added a commit that references this issue
on Feb 16, 2024
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:
fpcan be detected at runtime but can't be enabled. It is instead implied by theneonfeature.pmullcan be detected at runtime but can't be enabled. It is instead implied by theaesfeature, and all the related intrinsics use theaestarget feature.cc @JamieCunliffe @adamgemmell @workingjubilee