efriedma-quic wrote:
We briefly discussed this in the clang area team meeting, and we weren't really
happy with the design as-is. The underlying idea behind the feature makes
sense, but semantics of the actual builtin is ugly: there's a loose connection
between the condition check, and the region of code it's guarding.
I spent a bit more time thinking about it after the meeting. Here's a
potential alternative design: we add a new kind of if statement, a
"processor-feature-if", spelled something like `if
__amdgcn_processor_is("gfx900") {}`. In the body of the if statement, you're
allowed to use builtins that would otherwise be illegal. This ensures a direct
connection between the feature check and the corresponding builtins, so the
frontend can analyze your usage and generate accurate diagnostics.
In the case where the target features are known during clang codegen, lowering
is easy: you just skip generating the bodies of the if statements that don't
match. If you want to some kind of "runtime" (actual runtime, or SPIR-V
compilation-time) detection, it's not clear what the LLVM IR should look like:
we only support specifying target features on a per-function level. But we can
look at that separately.
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
