[clang] [llvm] Explicit types in cbuffer layouts (PR #156919)

Steven Perron via llvm-commits llvm-commits at lists.llvm.org
Tue Sep 9 11:33:28 PDT 2025


s-perron wrote:

I'm seeing a problem for SPIR-V that we may need to work out. I understand why you do it, and I don't have a solution yet.

```
// This struct has a size of 12 bytes (float + float2).
// In a cbuffer array, HLSL layout rules require each element to start on a
// 16-byte boundary. This means the compiler must insert 4 bytes of padding
// after each element.
struct PaddedStruct
{
    float f;
    float2 v2;
};

cbuffer MyCBuffer : register(b0)
{

    // The last element of the array is peeled.
    // @myArray = external hidden addrspace(12) global <{ [3 x <{ %PaddedStruct, [4 x i8] }>], %PaddedStruct }>, align 1
    PaddedStruct myArray[4];
    float anotherValue;
};

RWStructuredBuffer<float4> output : register(u0);

[numthreads(1, 1, 1)]
void main(uint3 dispatchThreadID : SV_DispatchThreadID)
{
    uint index = dispatchThreadID.x % 4;
    // The GEP associated with indexing into the array will use a GEP on i8 and could overflow the
    // array on the struct. The array overflow to get the next element in the struct is illegal in spir-v.
    float2 value = myArray[index].v2;

    // Use the value after the array to ensure it's not optimized out.
    output[0] = float4(value, 0.0f, anotherValue);
}
```




https://github.com/llvm/llvm-project/pull/156919


More information about the llvm-commits mailing list