spirv-opt produces illegal DebugSourceContinued op ordering

[cheneym2]

In the Non-Semantic.Shader.DebugInfo spec, the text says that DebugSourceContinued must follow DebugSource or DebugSourceContinued.

"The previous instruction must be a DebugSource or DebugSourceContinued instruction. The previous instruction must use the same extended instruction set <id> as this one, and it must contain some text string id."

https://github.com/KhronosGroup/SPIRV-Registry/blob/main/nonsemantic/NonSemantic.Shader.DebugInfo.100.asciidoc#DebugSourceContinued

Taking spv input which obeys that constraint, spirv-opt outputs optimized spirv that violates that constraint.

Notice how DebugSourceContinued follows DebugSource in the input, but it follows DebugCompilationUnit in the output.

$ diff ./repro.spvasm ./repro-spirvopt.spvasm
4c4
< ; Bound: 38
---
> ; Bound: 39
623d622
<           %4 = OpExtInst %void %2 DebugSource %5 %1
628,631d626
<          %10 = OpExtInst %void %2 DebugCompilationUnit %uint_100 %uint_5 %4 %uint_11
<          %12 = OpExtInst %void %2 DebugSource %13 %11
<          %15 = OpExtInst %void %2 DebugSourceContinued %14
<          %17 = OpExtInst %void %2 DebugSource %18 %16
634d628
<          %22 = OpExtInst %void %2 DebugTypeFunction %uint_0 %void
637,638d630
<          %24 = OpExtInst %void %2 DebugFunction %25 %22 %17 %uint_20 %uint_6 %10 %25 %uint_0 %uint_20
<          %30 = OpExtInst %void %2 DebugEntryPoint %24 %10 %31 %32
641a634,640
>           %4 = OpExtInst %void %2 DebugSource %5 %1
>          %10 = OpExtInst %void %2 DebugCompilationUnit %uint_100 %uint_5 %4 %uint_11
>          %15 = OpExtInst %void %2 DebugSourceContinued %14
>          %17 = OpExtInst %void %2 DebugSource %18 %16
>          %22 = OpExtInst %void %2 DebugTypeFunction %uint_0 %void
>          %24 = OpExtInst %void %2 DebugFunction %25 %22 %17 %uint_20 %uint_6 %10 %25 %uint_0 %uint_20
>          %30 = OpExtInst %void %2 DebugEntryPoint %24 %10 %31 %32
645c644
<          %29 = OpExtInst %void %2 DebugScope %24
---
>          %37 = OpExtInst %void %2 DebugScope %24
647a647
>          %38 = OpExtInst %void %2 DebugNoScope

To repro rename attached repro.txt to repro.spv, then:

./spirv-opt.exe repro.spv -o repro-spirvopt.spv -Os
./spirv-dis.exe repro-spirvopt.spv -o repro-spirvopt.spvasm

I've renamed the binary SPV input "repro.spv" to "repro.txt" so github will allow me to attach it,

repro.txt

Here's the disassembly for convenience:

repro_disassembly.txt

Issue was reproduced with spirv-opt 1.4.304.0?

[s-perron]

I cannot reproduce with the latest SPIR-V: https://godbolt.org/z/WK5xvonEj. I'll try reproducing locally.

[s-perron]

I cannot reproduce locally either. I wonder if there is a source of non-determinism. That is cause it to sometime output in a different order. For example, a hash map is used to store instructions and then it is iterated over to output the instructions.

[s-perron]

My team will not get to this any time soon. If is it a problem for slang, they might want someone to look into it, especially if they have an environment where it reproduces.

[cheneym2]

Are you able to reproduce it with SPIRV-Tools 1.4.304.0? That was the version of spirv-opt I reproduced with. I'll add that info in the bug description.