AlexVlx wrote: > Right, I don't see any semantic reason why `__builtin_cpu_is` or > `__builtin_cpu_supports` shouldn't be resolved statically if we have that > information on hand. `-mcpu` / `-march` are not usually sufficient for > folding `__builtin_cpu_is`, since those attributes just specify a minimum > architecture and the builtin is doing an exact check, but that's emergent and > shouldn't be taken as an inherent limitation of the builtin.
This would be up to the target to evaluate, as it'd have knowledge of whether the argument to the call is sufficient. When I initially implemented this, I added additional `supportsConstEvalCpuIs` and a `tryToFoldCpuIs` interfaces (name is up for bikeshedding) to the `TargetInfo` base, and then a target would be in a position to choose whether to implement those and what to do about it. For example, in our case, the entire ExpandPredicate stuff from this patch would've ended up as the implementation for the fold attempt. As I said, if folks would prefer that (or if they just want `__builtin_cpu_is` to gain the abilities), I can either switch `__builtin_amdgcn_processor_is` back to that or create a separate PR. Slightly independently, `cpu_supports` might turn out a bit difficult to use, at least for us (and I suspect other targets), as the feature definitions are often ad hoc and sadly mutable. Hence, telling users to check for this or that particular feature would be brittle and intrusive (we define features in a way that makes sense for the BE primarily, and don't really document them). Conversely, builtin names are somewhat more stable and easier to reason about. https://github.com/llvm/llvm-project/pull/134016 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
