[DirectX] Accessing a cbuffer array with a dynamic index hits an assertion error or generates incorrect code

[Icohedron]

Compiling the following shader results in an assertion error (if compiled with assertions enabled) or incorrect code generated (if no assertions are enabled) when compiled under clang: https://godbolt.org/z/5Yszfrx1K

clang-dxc -E CSMain -T cs_6_2 -enable-16bit-types

RWStructuredBuffer<uint32_t> output;
cbuffer Constants {
  uint32_t v[2];
}
[numthreads(1, 1, 1)] 
void CSMain(uint3 Tid : SV_DispatchThreadID) {
  output[Tid.x] = v[Tid.x];
}

clang-dxc: /workspace/llvm-project/llvm/lib/Target/DirectX/DXILCBufferAccess.cpp:69: size_t getOffsetForCBufferGEP(GEPOperator *, GlobalVariable *, const DataLayout &): Assertion `Success && "Offsets into cbuffer globals must be constant"' failed.

llvm-project/llvm/lib/Target/DirectX/DXILCBufferAccess.cpp

Line 69 in 9e0186d

assert(Success && "Offsets into cbuffer globals must be constant");

The generated DXIL has the following incorrect cbuffer load instruction which always loads from index 0 instead of the thread id.

  %3 = call i32 @dx.op.threadId.i32(i32 93, i32 0) #2
  %4 = call %dx.types.CBufRet.i32 @dx.op.cbufferLoadLegacy.i32(i32 59, %dx.types.Handle %2, i32 0) #1, !dbg !101

The same shader will successfully compile and validate under dxc.

[Icohedron]

While this exact kind of cbuffer access is not present in DML shaders, indirect access via a function call is commonly used, such as:

uint32_t foo(uint32_t4 d[2], uint32_t i) { return d[i]; }
RWStructuredBuffer<uint32_t> output;
cbuffer Constants {
  uint32_t4 v[2];
  uint32_t a;
}
[numthreads(1, 1, 1)] 
void CSMain() {
  output[a] = foo(v, a);
}

These do not trigger the assertion error because the function parameter d is an alloca, and the contents of the cbuffer array v gets copied into the alloca using constant-indexed accesses. Thus the access to d is a regular array access and not a cbuffer access.