Vulkan pipeline creation hangs with dynamic indexing through member function

[Git-RoySun]

Issue Description

I found a case where vkCreateComputePipelines hangs when a dynamically indexed array is accessed through a member function of a struct stored in an RWStructuredBuffer. The generated SPIR-V passes spirv-val, and vkCreateShaderModule succeeds. The hang occurs during vkCreateComputePipelines, before the shader is ever executed.

Reproducer Code

const static uint MAX_SIZE = 1 << 22;

struct Map
{
    uint values[MAX_SIZE];

    uint hash(uint k)
    {
        return k;
    }

    uint get(uint index)
    {
        uint slot = hash(index);
        return this.values[slot];
    }
}

RWStructuredBuffer<Map> hash_map;
RWStructuredBuffer<uint> output;

[shader("compute")]
[numthreads(16, 16, 1)]
void trace_ray(uint3 threadId : SV_DispatchThreadID)
{
    output[0] = hash_map[0].get(threadId.x);
}

Changing the MAX_SIZE to much smaller values like 1024 works, however, sizes like 16384 still hang. Making the hash or get free functions work as well.

Expected Behavior

• vkCreateComputePipelines should succeed

Actual Behavior

• Slang compilation succeeds.
• spirv-val accepts the generated SPIR-V.
• vkCreateShaderModule succeeds.
• vkCreateComputePipelines hangs. - The shader is never dispatched/executed.

Environment

• Slang Version 2026.8
• OS: Windows 11
• Vulkan ver: 1.4.351
• NVIDIA driver version: 616.56.0.0

[nv-slang-bot]

Triage — root cause identified

• Status: Triaged → handed to slang-fixer, fix incoming. Classified bug / high / P2, component IR lowering → SPIR-V emit. Issue Type set to Bug.
• Link: Root cause verified locally by disassembling the emitted SPIR-V on top-of-tree (master, 2026.13.1-50-g3649fb982).
• Verdict — why it hangs: A non-mutating member method on an RWStructuredBuffer<T> element passes its implicit this by value. When T holds a huge fixed array, the emitted SPIR-V therefore materializes a copy of the entire element into a Function-storage local — a whole-element OpLoad + OpCopyLogical + OpStore into a %_ptr_Function__arr_uint_int_4194304 variable (~16 MB at 1<<22) — and then indexes that local by the runtime slot. Because the local is dynamically indexed, SSA/mem2reg can't eliminate it, so the giant private-array copy survives to the final module. The SPIR-V is valid (hence spirv-val and vkCreateShaderModule succeed), but the sheer size of that array is what makes the NVIDIA driver's pipeline compiler hang at vkCreateComputePipelines. A free function, [mutating], or [constref] all pass the element by pointer instead, so the compiler emits a direct storage-buffer access chain to the single accessed uint — no copy, no hang.
• Next-action: slang-fixer to implement the fix — recommended approach is to stop materializing a by-value copy for a large non-mutating receiver at IR lowering (promote it to a borrow/pointer, generalizing the already-clean [constref] path). A draft PR will follow.
• Blocker: None for triage. Note: the hang is a GPU/driver runtime path, so it cannot be reproduced on this CI-only (no-GPU) environment — I reproduced and confirmed the underlying compiler artifact (the whole-element private-array copy) on top-of-tree, but I have not applied a reproduced label since the observable hang requires a Vulkan device.

Workaround until a fix lands: mark the method [constref] (e.g. [constref] uint get(uint index) { ... }), or use a free function taking the element by value — both make Slang access the buffer element by pointer and avoid the large copy.

_{🤖 Generated by an automated Slang coworker — may be inaccurate. A human maintainer should verify.}

[tangent-vector]

I think the bot is a little off-base in what it's recommending.

First of all, despite the good intentions of whoever added it, the [constref] attribute should not be treated as a supported feature of the language/compiler. It will definitely not retain that name in the long run, and we need to actually put a feature like that through a real testing and validation process before we OK it for users. Please don't write code using [constref] unless you are okay with future language/compiler changes potentially breaking your code, and with the fact that in the near term there might be cases where the feature is broken and doesn't work as you hope.

Back on the actual issue, I would like to request that the original requester (@Git-RoySun) provide a more complete example of the free-function variant that they are saying does work for them.

The bot's response quickly zeroed in on by-value vs. by-reference parameters, but the parameters of free functions are also by-value by default. The hash and get functions in the original repro should be compiled by the Slang compiler almost exactly as if they were free functions written as:

uint Map_hash(Map _this, uint k)
{
    return k;
}

uint Map_get(Map _this, uint index)
{
    uint slot = hash(_this, index);
    return _this.values[slot];
}

If writing free functions exactly like those also reproduces the problem, then the root cause is unrelated to the operations being methods.

My suspicion is that when somebody thinks of "equivalent" free functions, they might write something like:

uint Map_get(RWStructuredBuffer<Map> hash_map, uint map_index, uint key_index)
{
    uint slot_index = hash(key_index);
    return hash_map[map_index].values[slot_index];
}

If that's the free function we're comparing against, then it isn't really an apples-to-apples comparison, since the latter is passing a reference type (the RWStructuredBuffer) whereas the original was passing a value type (the Map corresponding to one element).

I'd like us to be sure we have an actual minimized reproducer that shows exactly the scenario where the problem first arises, and strips out any inessential complexity. If using a method instead of a module-scope function isn't actually a factor, we shouldn't focus on it.

[nv-slang-bot]

Thank you @tangent-vector — you're right on all three points, and I've walked back the earlier guidance. Correcting the record:

1. Retracting the [constref] recommendation. Understood that [constref] is not a supported feature, will not keep that name, and shouldn't be used. My earlier workaround suggestion was wrong to include it — please disregard it.

2. "Member function" was a red herring — confirmed by your desugaring. I re-ran the SPIR-V disassembly on top-of-tree (2026.13.1-50-g3649fb982) using the exact free-function form you wrote, and it reproduces the whole-element copy identically:

• Map_get(Map _this, uint i) { uint s = Map_hash(_this, i); return _this.values[s]; } — with Map_hash taking _this — called as Map_get(hash_map[0], tid.x) → reproduces the multi-MB Function-storage array copy.
• The member version does the same, and for the same reason: get calls this.hash(index), which passes the whole this value into a second function.

My earlier "free function works" claim was not apples-to-apples — exactly your suspicion. The free variant I tested had hash take only the key (not the struct), so the struct value had a single use and got narrowed away. When the struct value is threaded through the nested call the way the method actually desugars, the free function copies too.

3. The real trigger. It isn't methods, and it isn't by-value-vs-by-reference per se. The whole-element StructuredBufferLoad gets narrowed to just the accessed leaf only when every use of the loaded struct value is a field/element access chain. As soon as one use passes the whole struct value elsewhere — a live call taking it by value — the load can no longer be narrowed, so the entire element is materialized into a dynamically-indexed Function-storage local, which can't be scalarized and survives as a multi-MB private-array copy. Evidence at values[1 << 22]:

Form	Whole struct value passed to a live call?	Result
m.values[i] only (one access)	no	narrowed, clean
m.values[i] + m.values[j] (two accesses)	no	narrowed, clean
useWholeValue(m); … m.values[i] (live call use)	yes	whole-element copy
passing RWStructuredBuffer<Map> (a reference)	n/a (reference, not a value)	clean

Minimized reproducer (no methods, isolates the trigger):

struct Map { uint values[1 << 22]; }
uint useWholeValue(Map m) { return m.values[0]; }              // a live use of the whole value
uint get(Map m, uint index) { uint t = useWholeValue(m); return m.values[index] + t; }
RWStructuredBuffer<Map> hash_map;
RWStructuredBuffer<uint> output;
[shader("compute")]
[numthreads(1, 1, 1)]
void computeMain(uint3 tid : SV_DispatchThreadID) { output[0] = get(hash_map[0], tid.x); }

Deleting the useWholeValue(m) line makes it clean. (A call whose result is unused is dead-code-eliminated, which also removes the trigger — the whole-value use has to be live.)

@Git-RoySun — to make sure we compare like-for-like, could you paste the exact free-function version that worked for you? Our reading is that it likely passed the buffer itself (RWStructuredBuffer<Map>, a reference) rather than a Map value, which is why it avoided the copy — but your exact code would confirm it.

_{🤖 Generated by an automated Slang coworker — may be inaccurate. A human maintainer should verify.}

[Git-RoySun]

Hey, thanks for looking at this. Here is the exact code that I have tested:

const static uint MAX_SIZE = 1 << 22;

struct Map
{
    uint values[MAX_SIZE];

    uint hash(uint k)
    {
        return k;
    }

    uint get(uint index)
    {
        uint slot = hash(index);
        return this.values[slot];
    }
}

uint free_hash(uint k)
{
    return k;
}

uint free_get(Map _this, uint index)
{
    uint slot = free_hash(index);
    return _this.values[slot];
}

[[vk::binding(2, 0)]]
RWStructuredBuffer<Map> chunk_map;

[[vk::binding(0, 1)]]
RWTexture2D<float4> output;

[shader("compute")]
[numthreads(16, 16, 1)]
void trace_rays(uint3 threadId : SV_DispatchThreadID)
{
    //output[0] = chunk_map[0].get(threadId.x);
    output[0] = free_get(chunk_map[0], threadId.x);
}

The behavior for this code is the same as described in the issue: calling get does not work but calling free_get does. Swapping hash for free_hash in the get function body works as well. The two versions yield different results, and I don't think they are equivalent.

Not sure if it is related; however, I have noticed a hard limit of 1<< 21 in my actual code. It is a hash map implementation similar to the free function version I provided, but unlike here, it is actually dispatched and runs; however, I believe it never terminates, as it causes VK_ERROR_DEVICE_LOST when the size is set to 1<<22. Since changing the size to 1<<21 works, I don't think I have an infinite loop.

[nv-slang-bot]

Thanks @Git-RoySun — this is exactly the like-for-like pair we needed, and it confirms the (re-scoped) root cause.

The two are indeed not equivalent, and your own observation pinpoints why: the difference isn't method-vs-free, it's whether the whole Map value is passed into a live call.

• In get, hash is a method, so hash(index) is really this.hash(index) — it passes the entire Map value into a second call. That whole-value use blocks the compiler's buffer-load optimization, so the entire Map element (~16 MB at 1<<22) is copied into a local array that is then dynamically indexed — and that giant local is what the driver chokes on at vkCreateComputePipelines.
• In free_get, free_hash(index) does not take _this, so _this is only ever field-accessed (_this.values[slot]). The optimization then narrows the read down to the single uint actually used — no whole-element copy, no hang.

That's also why swapping hash→free_hash inside get fixes it: it removes the whole-value call. So "member function" was a red herring; the trigger is a large-array struct value being passed by value into a live call (which is what a non-[mutating] method call on a buffer element does with this). Appreciate you nailing it down so precisely.

On the 1<<22 VK_ERROR_DEVICE_LOST: thanks for flagging it — I think that's most likely a separate issue from the one tracked here. This issue is a compile-time hang: it happens in vkCreateComputePipelines, before anything is dispatched, and only in the variant that produces the giant local copy. Your device-lost is in the working (free_get) variant that compiles and dispatches, i.e. no such copy — so it looks like a runtime concern (a genuinely huge 16 MB-per-element array causing a timeout/TDR or hitting a device/resource limit) rather than the codegen problem here. I can't reproduce runtime behavior without a GPU, so if it keeps biting after the compile-time fix lands, a separate issue with the device-lost details (validation-layer / GPU-crash-dump output, whether it repros with a single dispatched element, etc.) would be the best way to track it — happy to help dig in there.

The compile-time fix itself touches a subtle correctness area in the compiler's buffer-load handling, so we're leaving the exact approach to the Slang maintainers. Thanks again for the clean reproducer.

_{🤖 Generated by an automated Slang coworker — may be inaccurate. A human maintainer should verify.}

[jkwak-work]

I think bot root-caused the problem:

In get, hash is a method, so hash(index) is really this.hash(index) — it passes the entire Map value into a second call.

I am not sure how to fix/improve the situation.
We will discuss more in the next meeting.

[nv-slang-bot]

Thanks @jkwak-work — glad the root cause landed, and taking the fix to the meeting makes sense.

Status: Handed off — root cause confirmed by the Slang team; fix approach pending your next meeting.
Root cause (confirmed): a value-type struct with a large array, loaded from a structured buffer, is passed by value into a live call (here this.hash(index) threads the whole Map), which prevents the buffer-load from being narrowed to the accessed element — so the entire element is materialized as a dynamically-indexed local array (~16 MB at 1<<22) that the driver's pipeline compiler hangs on. Method-vs-free is incidental; the trigger is the whole-struct-into-a-call.
Next action: Slang team to pick the fix layer at the meeting; a fixer is ready to implement + run full regression once a direction is chosen.
Resumes on: the team's fix-layer decision.
Blocker: none — this is a resting handoff, not a stall.

In case it's useful for the discussion, here's the precise spot the narrowing stops (traced in the IR on top-of-tree), offered as input, not a prescription:

• specializeFuncsForBufferLoadArgs already does its job: it drops the by-value Map parameter and defers a whole-element load into the callee — %39 = load(rwstructuredBufferGetElementPtr(hash_map, idx)) — whose single use is a get_field (field extract).
• deferBufferLoad would then normally narrow that to load only the used element. It does exactly that for the call-free helper. But in get it declines in deferBufferLoadInst (source/slang/slang-ir-defer-buffer-load.cpp): the buffer is mutable, so narrowing requires isMemoryLocationUnmodifiedBetweenLoadAndUser, which returns false because the intervening call between the load and the get_field hits the conservative default: return false for side-effecting instructions. So the whole-element load survives → the giant local copy.
• Correctness boundary (why it can't just be relaxed): deferBufferLoad moves the load down to the extract, so deferring across a call that actually wrote that element would change the value observed. The conservatism is sound in general; the only safe relaxation is when the intervening call provably cannot write a location aliasing the load — i.e. it needs call mod/ref (alias) or read-only-callee information. That representation/analysis question is the layer decision, which is why we've left it to the team rather than prescribing it here.

_{🤖 Generated by an automated Slang coworker — may be inaccurate. A human maintainer should verify.}