Indexing into array generates invalid code in CUDA and Vulkan

[tdavidovicNV]

Issue Description

When array member of a struct is indexed by an int member of the struct, Slang generates invalid code on at least CUDA and Vulkan.

Reproducer Code

import playground;
import rendering;

struct ColorChooser
{
    int color_index;
    float3 color[2];

    float3 get_color()
    {
        var result = float3(1, 0 , 0);
        if (color_index >= 0 && color_index < 2)
            result = color[color_index];
        return result;
    }
};

[shader("compute")]
[numthreads(16, 16, 1)]
[playground::CALL::SIZE_OF("outputTexture")]
void imageMain(uint2 dispatchThreadID: SV_DispatchThreadID, uniform ColorChooser chooser)
{
    float3 color = chooser.get_color();
    drawPixel(dispatchThreadID, (int2 _) => float4(color, 1));
}

on CUDA, this generates this access to color[2]:

#line 12
        result_0 = this_0->color_0[&this_0->color_index_0];

trying to use the address of color_index as the index, rather than the actual value.

The code from which this reproducer was taken also failed to compile to SPIR-V when the same pattern was used, but the problem isn't immediatelly from the generated SPIR-V code.

Expected Behavior

The expected behavior is to work in this fashion:

    float3 get_color()
    {
        var result = float3(1, 0 , 0);
        if (color_index == 0)
            result = color[0];
        else if (color_index == 1)
            result = color[1];
        return result;
    }

Actual Behavior

Slang generates invalid code that the backend compiler just fails to compile.

[tdavidovicNV]

Changing the ColorChooser to this:

struct ColorChooser
{
    int color_index;
    float3 color[2];

    float3 get_color()
    {        
        return get_color(color_index);
    }

    float3 get_color(int index)
    {
        var result = float3(1, 0 , 0);
        if (index >= 0 && index < 2)
            result = color[index];
        return result;
    }
};

So the member variable isn't accessed directly by passed to another call as a parameter resolves the issue.

[bmillsNV]

Might be fixed by #9113

[bmillsNV]

Tomas will see if this issue is resolved w/9113

[tdavidovicNV]

@bmillsNV I can confirm this has been resolved on the current Slang's ToT, probably by the #9113