================
@@ -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);
----------------
bogner wrote:
So this pattern is going to get really annoying really fast. I think there are
two approaches to how we can handle this in a better way:
1. Use TargetLibraryInfo or something similar, where backends can register
their own support for getting the right intrinsics for this kind of thing.
2. Add a tool in llvm/lib/Frontend/HLSL that knows the answers for SPIR-V and
DXIL
I suspect (1) is a more robust solution, but it has a couple of problems.
Notably it's a big thing to design and it isn't entirely clear that it's all
that useful outside of DXIL and SPIR-V, especially in the short term. I don't
think we should do this now.
For (2) though, we could probably just have a .def file that maps the DXIL and
SPIR-V intrinsics to a generic enum, or alternatively just a set of getters for
the intrinsics we care about. Then this just looks like
HLSLIntrinsic::get(threadid) or HLSLIntrinsic::getThreadID() or something to
that effect. WDYT?
https://github.com/llvm/llvm-project/pull/82536
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
