thread 'main' panicked at 'assertion failed: prev.is_none()', src/front/spv/mod.rs:2903:25

[Jack-Clark]

Running:

target/debug/naga break-error.spv break-error.comp

Gives:

thread 'main' panicked at 'assertion failed: prev.is_none()', src/front/spv/mod.rs:2903:25
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Aborted (core dumped)

If I run a release build, then I get:

Function [1] '' is invalid: 
	The `break` is used outside of a `loop` or `switch` context
Generating glsl output requires validation to succeed, and it failed in a previous step

I can also produce a slightly different error in both debug and release mode using a different example:

target/release/naga continue-error.spv continue-error.comp

Outputs:

Function [1] '' is invalid: 
	The `continue` is used outside of a `loop` context
Generating glsl output requires validation to succeed, and it failed in a previous step

I've tried .comp .metal and .hlsl as translation targets and I get the same result regardless. I reproduced this on main (commit b3d5e6d). Here is an archive with the code examples

[teoxoy]

Thanks for the report!

This looks like some more complex (relative to what we are currently handling) control flow.

I generated the following images via spirv-cfg and dot -Tpng.

continue-error

break-error

I'm not familiar with SPIR-V's control flow @kvark or @JCapucho might know more.

[Jack-Clark]

No problem! Here is an archive containing a simpler example for the break-error case. This has the following CFG:

[JCapucho]

The problem is that our BranchConditional code expects to either branch to a new block or to a merge/continue block, these expectations are mostly correct with the slight problem that one block of a loop (called back-edge) can branch into the loop header, this block must post dominate the continue target so a quick fix for your problem would be to allow branches to the loop header but this would break in the following pseudocode example:

loop {
  continuing {
    if condition {
      branch_to_loop_header
    }
    
    // some code
  }
}

which would be something like the following spirv:

%11 = OpLabel
      OpLoopMerge %merge %continue None
      OpBranch %14
%14 = OpLabel
      OpBranch %13
%continue = OpLabel
      OpBranchConditional %condition %11 %12
%12 = OpLabel
      // some code

Here the back-edge is %continue and it follows the condition of being post dominate but if we used the quick fix this would generate the following wgsl:

loop {
  continuing {
    if condition { }
    
    // some code
  }
}

while we want to generate

loop {
  continuing {
    if condition { }
    else {
      // some code
    }
  }
}

[eddyb]

I suspect this is a duplicate of:

• [spv-in] Conditional loop backedge not lowered to Statement::Loop with break_if expression naga#1977

I have a fix open for that, can you try it out on your input?

• [spv-in] Convert conditional backedges to break if. naga#2290