Keenuts wrote: > For the HLSL FE, there are already a few ids represented using intrinsics > (unfortunately they use the DXIL naming rather than the SPIR-V but that's > another point). I extended on that, were there reasons to not pursue this ?
The main reason was simplicity: we had many things to work on (structurizer, basic entrypoint handling), and we needed at least 1/2 builtins to get started. Following what OpenCL has been doing for other built-ins was the path with the less friction. Once we have a few implemented to start building the rest (structurizer, etc), we started to look into a more generic approach to handle input/output builtins in HLSL->SPV. The proposal I wrote at the time is here: https://github.com/llvm/wg-hlsl/pull/97 In short: for input builtins, I don't see issues with using pure intrinsics. For output builtins, there is an issue in doing so. To avoid having different handling for inputs & outputs, we settled on handling both using globals (which is compatible with the output side-effect). That said, I'm not completely against having 2 ways to do the same thing in the backend if that's really a requirement on your end. Some FE could use intrinsics, other the global approach. @s-perron FYI https://github.com/llvm/llvm-project/pull/143909 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
