AlexVlx wrote: > It's been awhile since I've looked at this. From what I understand, what we > want is basically a `__builtin_cpu_supports` that's resolved by the backend > rather than runtime. That's presumably just checking the feature set of the > target, either through the function's attributes or default set. Is what > we're doing here fundamentally different?
This is (AMDGCN flavoured) SPIR-V specific. So yes, it is somewhat different, as the resolution would occur on SPIR-V, not on LLVM IR (there's no "resolved by backend", whatever that means), because SPIR-V has a defined concept / solution for this sort of thing, in the form of specialisation constants. This is different from the prior iteration, which wanted to do resolution on LLVM IR, which led to issues. From the perspective of the user / client app, there is no difference from what you describe (except for the fact, as has been argued previously, `__builtin_cpu_support` is meant to resolve at run time, at least with its current design, whereas these would never truly resolve at run time, they'd either be expanded in the FE for concrete targets, or in SPIR-V when we JIT). https://github.com/llvm/llvm-project/pull/134016 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
