Fix invalid SPIRV from continue inside switch inside for loop

When a `continue` statement appears inside a `switch` nested within a `for`
loop, the `eliminateMultiLevelBreak` pass failed to detect the branch from
inside the switch to the loop's continue block as a multi-level branch. This
caused the raw IR branch to reach the SPIRV emitter, producing unstructured
control flow that spirv-val rejects.

Root cause: for `for`-loops, the continue block is distinct from the loop's
target block. `populateExitBlocks()` stored `continueBlock` but did not add
it to the region's `exitBlocks` list, so `mapExitBlockToRegion` never mapped
it to the loop region, and `gatherInfo()` never flagged the branch as a
multi-level branch. As a result, `eliminateContinueBlocksInFunc()` was never
triggered to transform the IR into valid SPIRV structured form.

Fix: when `continueBlock != targetBlock`, add `continueBlock` to
`region->exitBlocks` so it participates in multi-level branch detection.
This triggers `eliminateContinueBlocksInFunc()`, which wraps the loop body
in an inner breakable region; the `continue` from inside the switch then
becomes a break from that region — a valid SPIRV structured exit.

Also fix a related leak: after processing a region, pop `continueBlock`
from the global `exitBlocks` stack unconditionally, covering the while-loop
case where `continueBlock == targetBlock` and it was not in `exitBlocks`.

Fixes #9585, #10198.

Author: jkwak-work

source/slang/slang-ir-eliminate-multilevel-break.cpp

@@ -71,8 +71,24 @@ struct EliminateMultiLevelBreakContext
             // If this is a loop, store the continue block.
             // We add it to the exitBlocks stack separately in collectBreakableRegionBlocks
             // so that nested constructs treat it as an exit point.
-            if (as<IRLoop>(headerInst))
+            if (auto loop = as<IRLoop>(headerInst))
+            {
                 continueBlock = getContinueBlock();
+                // When the continue block is a distinct block from the loop's target block,
+                // also add it to the region's exitBlocks. This ensures that branches from
+                // nested constructs (e.g. a switch case with `continue` inside a for-loop)
+                // to the loop's continue block are detected as multi-level branches and
+                // handled correctly by this pass.
+                //
+                // When continueBlock == targetBlock (common for while-loops), we do NOT add
+                // it here to exitBlocks, because the target block is already part of the
+                // loop region's block set and adding it as an exit block would cause
+                // duplicate key errors when building the block-to-region mapping.
+                // In that case, we still push continueBlock to the exitBlocks stack in
+                // collectBreakableRegionBlocks, so nested constructs treat it as an exit.
+                if (continueBlock && continueBlock != loop->getTargetBlock())
+                    exitBlocks.add(continueBlock);
+            }
         }
 
         void replaceBreakBlock(IRBuilder* builder, IRBlock* block)
@@ -180,6 +196,10 @@ struct EliminateMultiLevelBreakContext
             // Pop the exit blocks.
             for (auto exitBlock : info.exitBlocks)
                 exitBlocks.remove(exitBlock);
+            // Also pop the continueBlock if it was pushed separately (when continueBlock ==
+            // targetBlock it is not in info.exitBlocks but was still pushed to the stack above).
+            if (info.continueBlock)
+                exitBlocks.remove(info.continueBlock);
         }
 
         void gatherInfo(IRGlobalValueWithCode* func)

tests/bugs/gh-10198-continue-in-switch-in-for-spirv.slang

@@ -0,0 +1,52 @@
+// Regression test for issue #10198:
+// "Invalid SPIRV: `continue` inside `switch` inside `for` produces unstructured control flow"
+//
+// A `continue` inside a switch case inside a `for` loop was producing invalid SPIRV.
+// The root cause was in eliminateMultiLevelBreak: the loop's continue block (which is
+// a distinct block from the loop's target in a for-loop) was not being added to the
+// region's exitBlocks, so branches from inside the switch to the continue block were
+// not detected as multi-level branches requiring transformation.
+//
+// This test verifies both correctness and that SPIRV validation passes.
+
+//TEST:SIMPLE(filecheck=CHECK): -target spirv -stage compute -entry computeMain -emit-spirv-directly
+//TEST:COMPARE_COMPUTE(filecheck-buffer=CBUF): -output-using-type -cpu
+
+// CHECK: OpEntryPoint
+
+//TEST_INPUT:ubuffer(data=[0], stride=4):out,name=outputBuffer
+RWStructuredBuffer<int> outputBuffer;
+
+int test(int value)
+{
+    int result = 0;
+    for (int i = 0; i < 3; i++)
+    {
+        switch (value)
+        {
+        case 0:
+            result += 1;
+            continue; // triggers the bug: continue from switch inside for-loop
+        case 1:
+            result += 2;
+            break;
+        default:
+            result += 3;
+            break;
+        }
+        result += 10;
+    }
+    return result;
+}
+
+[shader("compute")]
+[numthreads(1, 1, 1)]
+void computeMain()
+{
+    // test(0): case 0 hits, result += 1, continue (skips +10) -> 3 iterations -> result = 3
+    // test(1): case 1 hits, result += 2, break, then +10 -> 3 iterations -> result = 36
+    // test(2): default hits, result += 3, break, then +10 -> 3 iterations -> result = 39
+    // total = 3 + 36 + 39 = 78
+    outputBuffer[0] = test(0) + test(1) + test(2);
+    // CBUF: 78
+}

tests/bugs/gh-9585-continue-in-switch-in-for-spirv.slang

@@ -0,0 +1,46 @@
+// Regression test for issue #9585:
+// "For loop `continue` inside a `switch` breaks structured control flow"
+//
+// A `continue` inside a switch (with no other cases) inside a `for` loop was producing
+// invalid SPIRV. This is the simpler variant of #10198 — same root cause, same fix.
+//
+// Fixed in slang-ir-eliminate-multilevel-break.cpp by adding the loop's continueBlock
+// to region->exitBlocks when continueBlock != targetBlock (for-loops), so that branches
+// to it from inside nested switch constructs are treated as multi-level branches and
+// transformed into valid SPIRV structured control flow via eliminateContinueBlocksInFunc.
+
+//TEST:SIMPLE(filecheck=CHECK): -target spirv -stage compute -entry computeMain -emit-spirv-directly
+//TEST:COMPARE_COMPUTE(filecheck-buffer=CBUF): -output-using-type -cpu
+
+// CHECK: OpEntryPoint
+
+//TEST_INPUT:ubuffer(data=[0], stride=4):out,name=outputBuffer
+RWStructuredBuffer<int> outputBuffer;
+
+[shader("compute")]
+[numthreads(1, 1, 1)]
+void computeMain()
+{
+    int sum = 0;
+
+    for (int i = 0; i < 3; ++i)
+    {
+        sum += 1;
+
+        switch (i)
+        {
+        case 0:
+            {
+                continue; // continue from switch inside for-loop: the bug
+            }
+        }
+
+        sum += 10; // skipped when i==0 due to continue, executed for i==1,2
+    }
+
+    // i=0: sum += 1, continue (skip +10) -> sum=1
+    // i=1: sum += 1, no case match, sum += 10 -> sum=12
+    // i=2: sum += 1, no case match, sum += 10 -> sum=23
+    outputBuffer[0] = sum;
+    // CBUF: 23
+}