You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I hear that there was previously a principle that we would only add __ARM_FEATURE macros for features that have associated C/C++ intrinsics. However:
This is inconvenient for users who want to use other features in inline asm.
Some features do not add new intrinsics or language constructs, but do improve the performance of existing constructs. Users might want to test for such features too.
There are already macros like __ARM_FEATURE_ATOMICS that have no associated intrinsics. #199 adds another case. There are probably more macros besides these two (I've not gone through all the features to check).
It would be good if we retroactively added macros for existing “relevant” ISA features, to improve consistency. This probably needs a policy decision about where the new line should be drawn. E.g.:
all features with a FEAT_ identification
all features that have associated instructions, system registers, DC encodings, etc.
all features that have associated instructions
(1) feels a bit overboard, but both (2) and (3) seem plausible.
The text was updated successfully, but these errors were encountered:
I hear that there was previously a principle that we would only add
__ARM_FEATURE
macros for features that have associated C/C++ intrinsics. However:There are already macros like
__ARM_FEATURE_ATOMICS
that have no associated intrinsics. #199 adds another case. There are probably more macros besides these two (I've not gone through all the features to check).It would be good if we retroactively added macros for existing “relevant” ISA features, to improve consistency. This probably needs a policy decision about where the new line should be drawn. E.g.:
(1) feels a bit overboard, but both (2) and (3) seem plausible.
The text was updated successfully, but these errors were encountered: