[clang] [llvm] [HLSL][SPIR-V] Add SV_DispatchThreadID semantic support (PR #82536)
Natalie Chouinard via cfe-commits
cfe-commits at lists.llvm.org
Mon Mar 4 10:05:20 PST 2024
================
@@ -342,8 +343,19 @@ llvm::Value *CGHLSLRuntime::emitInputSemantic(IRBuilder<> &B,
return B.CreateCall(FunctionCallee(DxGroupIndex));
}
if (D.hasAttr<HLSLSV_DispatchThreadIDAttr>()) {
- llvm::Function *DxThreadID = CGM.getIntrinsic(Intrinsic::dx_thread_id);
- return buildVectorInput(B, DxThreadID, Ty);
+ llvm::Function *ThreadIDIntrinsic;
+ switch (CGM.getTarget().getTriple().getArch()) {
+ case llvm::Triple::dxil:
+ ThreadIDIntrinsic = CGM.getIntrinsic(Intrinsic::dx_thread_id);
+ break;
+ case llvm::Triple::spirv:
+ ThreadIDIntrinsic = CGM.getIntrinsic(Intrinsic::spv_thread_id);
+ break;
+ default:
+ llvm_unreachable("Input semantic not supported by target");
+ break;
+ }
+ return buildVectorInput(B, ThreadIDIntrinsic, Ty);
----------------
sudonatalie wrote:
Agreed this is not going to scale well. Another option I was looking into, but haven't yet figured out, is whether we could make dummy `ClangBuiltin`s to maintain the mapping. I think the appropriate `spv_create_handle` or `dx_create_handle` get generated without any special logic other than both having `ClangBuiltin<"__builtin_hlsl_create_handle">` in their `Intrinsics*.td`. I'll open an issue to follow up on this separately.
https://github.com/llvm/llvm-project/pull/82536
More information about the cfe-commits
mailing list