[HLSL] The type of the SV_GroupIndex semantic isn't validated correctly

[bogner]

If we mark a uint4 with the SV_GroupIndex semantic (rather than uint, as it should be), like so:

RWStructuredBuffer<float4> Buf : register(u0);

[numthreads(1,1,1)]
void main(uint4 GI : SV_GroupIndex) {
  Buf[GI.x] = 0;
}

We hit a fairly confusing assert during clang codegen:

Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i) == Args[i]->getType()) && "Calling a function with a bad signature!"), function init, file Instructions.cpp, line 748.
...
  * frame #4: 0x0000000102b7d7b0 clang-dxc`llvm::CallInst::init(this=0x0000600002cac360, FTy=0x000000013c82a320, Func=0x0000600002f82768, Args=ArrayRef<llvm::Value *> @ 0x000000016fdf2cd0, Bundles=ArrayRef<llvm::OperandBundleDefT<llvm::Value *> > @ 0x000000016fdf2cc0, NameStr=0x000000016fdf2d88) at Instructions.cpp:746:5
...
    frame #8: 0x0000000104158f78 clang-dxc`clang::CodeGen::CGHLSLRuntime::emitEntryFunction(this=0x00006000013ac0f0, FD=0x000000013ca12630, Fn=0x0000600002f82768) at CGHLSLRuntime.cpp:412:20

This is because we blindly create the intrinsic with without checking the type in emitInputSemantic, where we should really have an assert:

--- a/clang/lib/CodeGen/CGHLSLRuntime.cpp
+++ b/clang/lib/CodeGen/CGHLSLRuntime.cpp
@@ -343,6 +343,7 @@ llvm::Value *CGHLSLRuntime::emitInputSemantic(IRBuilder<> &B,
   if (D.hasAttr<HLSLSV_GroupIndexAttr>()) {
     llvm::Function *GroupIndex =
         CGM.getIntrinsic(getFlattenedThreadIdInGroupIntrinsic());
+    assert(GroupIndex->getType() == Ty && "Incorrect type for SV_GroupIndex");
     return B.CreateCall(FunctionCallee(GroupIndex));
   }
   if (D.hasAttr<HLSLSV_DispatchThreadIDAttr>()) {

The actual bug is that we aren't checking the type of SV_GroupIndex in SemaDeclAttr:

  case ParsedAttr::AT_HLSLSV_GroupIndex:
    handleSimpleAttribute<HLSLSV_GroupIndexAttr>(S, D, AL);
    break;

This doesn't do any semantic checking, so we allow any type through.

[damyanp]

We are expecting to do a more holistic fix for how semantics are handled and validated, but this seems like a useful stop-gap quick fix.