Description
When loading or storing a matrix to groupshared dxc is using an alignment on the instruction that is not guaranteed by the underlying global variable.
Steps to Reproduce
https://godbolt.org/z/9c9os31MW
// dxc /Tcs_6_0 alignbug.hlsl
struct Data {
float4x4 m;
};
groupshared Data GData;
StructuredBuffer<Data> input : register(t0);
RWStructuredBuffer<Data> output : register(u0);
[RootSignature("SRV(t0), UAV(u0)")]
[numthreads(128,1,1)]
void main(uint Id : SV_DispatchThreadId, uint g : SV_GroupID)
{
GData = input[0];
GroupMemoryBarrierWithGroupSync();
output[Id] = GData;
}
Actual Behavior
Compiling this shader produces loads and stores that do not match the alignment of the underlying global.
The global does not specify an alignment so it will get the default alignment of 4 for this type
@"\01?GData@@3UData@@A.0.v.v" = addrspace(3) global [16 x float] undef
But the load
%22 = load float, float addrspace(3)* getelementptr inbounds ([16 x float], [16 x float] addrspace(3)* @"\01?GData@@3UData@@A.0.v.v", i32 0, i32 0), align 16
and store
store float %3, float addrspace(3)* getelementptr inbounds ([16 x float], [16 x float] addrspace(3)* @"\01?GData@@3UData@@A.0.v.v", i32 0, i32 0), align 16
both specify an alignment of align 16 for the first element (other elements are overaligned as well).
From the llvm language reference manual, the aligment on the instruction should be guaranteed by somehow, but the alignment of the global does not do it.
The optional constant align argument specifies the alignment of the operation (that is, the alignment of the memory address). It is the responsibility of the code emitter to ensure that the alignment information is correct.
Environment
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4