[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