Load is moved past store with optimised SPIR-V input

[rossy]

I'm trying to debug this issue in mpv. It seems like a load is being migrated past a store in the HLSL output, but only when the shader is compiled with optimisations and a recent version of shaderc.

For example, this GLSL shader:

#version 450 core

layout(std430, binding=0) buffer SSBO {
	uint index;
	uint array[64];
};

void main()
{
	uint value = array[index];
	for (uint i = 0; i < 64; i++)
		array[i] = 0;
	array[index] = value;
}

When compiled without optimisation:

glslc -std=450core -g -fshader-stage=compute --target-env=vulkan test.comp -o test.comp.spv

Produces this SPIR-V, which produces the following HLSL when compiled with SPIRV-Cross. This seems like the correct translation of the above shader:

RWByteAddressBuffer _13 : register(u0, space0);

void comp_main()
{
    uint value = _13.Load(_13.Load(0) * 4 + 4);
    for (uint i = 0u; i < 64u; i++)
    {
        _13.Store(i * 4 + 4, 0u);
    }
    _13.Store(_13.Load(0) * 4 + 4, value);
}

[numthreads(1, 1, 1)]
void main()
{
    comp_main();
}

When compiled with optimisation:

glslc -std=450core -g -Os -fshader-stage=compute --target-env=vulkan test.comp -o test.opt.comp.spv

It produces this SPIR-V, which also seems correct. The loads and stores are still in the right order. But SPIRV-Cross produces this HLSL, which moves one of the loads for the array past the store for the same array:

RWByteAddressBuffer _13 : register(u0, space0);

void comp_main()
{
    for (uint _40 = 0u; _40 < 64u; )
    {
        _13.Store(_40 * 4 + 4, 0u);
        _40++;
        continue;
    }
    _13.Store(_13.Load(0) * 4 + 4, _13.Load(_13.Load(0) * 4 + 4));
}

[numthreads(1, 1, 1)]
void main()
{
    comp_main();
}

This probably also happens with glslValidator/spirv-opt output, but I haven't tested those.

[HansKristian-Work]

Sounds like a simple lack of expression invalidation, but surprising it's not happening here.

[HansKristian-Work]

Ok, verified. This bug only seems to trigger on HLSL backend, which is a bit weird. On GLSL and MSL, the expression is properly invalidated.

[HansKristian-Work]

Pretty dumb oversight after all.

[rossy]

It works now. Thanks for the fix.