MrSidims wrote:
> Thank you for the feedback! I might not be getting the question right (case
> in which I apologise in advance!), but I think that for "vanilla" SPIR-V i.e.
> not vendor flavoured one, where one strictly has to deal with Extensions /
> non-core capabilities, we probably would have the following situation:
I was imagining cases like this:
```
if (__builtin_amdgcn_processor_is("some_hw_with_fp16_support) {
/*code using fp16*/
} else {
/*code using fp32*/
}
```
note, that when translated to SPIR-V the SPIR-V generator must insert
**Float16** capability (in the beginning of the module). So such tool would
need to remove that capability as well.
A side question, is it legal to use the builtin in unstructured control flow,
like here: https://godbolt.org/z/qnhKdhfdW ?
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
