Perhaps for the dev-meeting, but I am inclined to argue that feature names (or at the very least their documentation) needs to clearly state which architecture they are intended for. Not so long ago, I got confused, as I wanted to do target.has_feature(Target::FMA), which returns false on most architectures that do have FMA support. The culprit of course is that Target::FMA is a feature flag meant to be used exclusively for x86 architectures. The problem here is that FMA and F16C, sound like functionalities, instead of specific instruction set extensions. I'd argue that complementary to documentation improvements, we could add Target::host_supports_fma() and Target::host_supports_f16_conversion() and Target::host_supports_f16_ops(), or something like this.

@mcourteaux @abadams I may be misunderstanding the broader context, but from what I can see, providing this functionality in a clean way would likely require moving away from the current subset/superset model and avoiding the pattern of treating architecture names as feature sets. Instead, I believe it would be better if each target explicitly listed its supported features one-by-one, ideally with target names composed only of features, not architecture labels.

The clear upside is that this avoids edge cases from implicit relationships, but the downside is the cost of changing existing code and maintaining consistency going forward, the increased verbosity from having to declare both feature-to-arch support and arch-to-feature mappings. Still, for finer-grained and unambiguous control, this may be a necessary step.

One concern I have is that some features may include architectural traits beyond instruction sets—such as register widths—which might complicate this approach. I’m not sure if that’s the case, so I’d appreciate any clarification on that.

@abadams If there are no other reviews or changes needed on this PR, would it be okay to go ahead and merge this first? I’d be happy to open a follow-up issue to continue this discussion and will mention the related discussions.

The conclusion from the dev meeting is that we're happy with this design. The only issue preventing a merge is that there appears to be a simd_op_check failure with llvm 18 (the two other failing bots are unrelated)

The issue was caused by the znver5 tuning flag not being supported in LLVM 18. I’ve updated the configuration to use znver5 only when LLVM version 19 or higher is detected, and to fall back to znver4 for earlier versions.

Failures are unrelated flakes

Thanks for this! I have merged it.