mlir deserialize spirv: "Cannot destroy a value that still has uses!"

[alex-s168]

On LLVM d81ffd4ebb45 (latest main at time of writing)

mlir-translate --deserialize-spirv on the input below causes an error error:

; SPIR-V
; Version: 1.0
; Generator: Khronos SPIR-V Tools Assembler; 0
; Bound: 14
; Schema: 0
               OpCapability Shader
          %1 = OpExtInstImport "GLSL.std.450"
               OpMemoryModel Logical GLSL450
               OpEntryPoint Fragment %2 "main"
               OpExecutionMode %2 OriginLowerLeft
       %void = OpTypeVoid
          %4 = OpTypeFunction %void
       %bool = OpTypeBool
      %false = OpConstantFalse %bool
          %2 = OpFunction %void None %4
          %7 = OpLabel
               OpBranch %8
          %9 = OpLabel
               OpSelectionMerge %10 None
               OpBranchConditional %false %11 %11
         %11 = OpLabel
               OpBranch %12
         %12 = OpLabel
               OpBranch %10
         %13 = OpLabel
               OpBranch %12
         %10 = OpLabel
               OpBranch %8
          %8 = OpLabel
               OpReturn
               OpFunctionEnd

(this was produced by using spirv-reduce on an glslang compiled glsl fragment shader)

error (minimized):

mlir-translate: mlir/include/mlir/IR/UseDefLists.h:198: mlir::IRObjectWithUseList<mlir::BlockOperand>::~IRObjectWithUseList() [OperandType = mlir::BlockOperand]: Assertion `use_empty() && "Cannot destroy a value that still has uses!"' failed.
Stack dump:
...
#12  mlir::Block::erase() Block.cpp:0:0
#13  mlir::spirv::Deserializer::structurizeControlFlow() Deserializer.cpp:0:0
#14  mlir::spirv::Deserializer::processFunctionEnd(llvm::ArrayRef<unsigned int>) Deserializer.cpp:0:0
#15  mlir::spirv::Deserializer::processFunction(llvm::ArrayRef<unsigned int>) Deserializer.cpp:0:0
#16  mlir::spirv::Deserializer::deserialize() Deserializer.cpp:0:0
#17  mlir::spirv::deserialize(llvm::ArrayRef<unsigned int>, mlir::MLIRContext*, mlir::spirv::DeserializationOptions const&) Deserialization.cpp:0:0

[llvmbot]

@llvm/issue-subscribers-mlir

Author: alex_s168 (alex-s168)

On LLVM `d81ffd4ebb45` (latest main at time of writing)

mlir-translate --deserialize-spirv on the input below causes an error error:

; SPIR-V
; Version: 1.0
; Generator: Khronos SPIR-V Tools Assembler; 0
; Bound: 14
; Schema: 0
               OpCapability Shader
          %1 = OpExtInstImport "GLSL.std.450"
               OpMemoryModel Logical GLSL450
               OpEntryPoint Fragment %2 "main"
               OpExecutionMode %2 OriginLowerLeft
       %void = OpTypeVoid
          %4 = OpTypeFunction %void
       %bool = OpTypeBool
      %false = OpConstantFalse %bool
          %2 = OpFunction %void None %4
          %7 = OpLabel
               OpBranch %8
          %9 = OpLabel
               OpSelectionMerge %10 None
               OpBranchConditional %false %11 %11
         %11 = OpLabel
               OpBranch %12
         %12 = OpLabel
               OpBranch %10
         %13 = OpLabel
               OpBranch %12
         %10 = OpLabel
               OpBranch %8
          %8 = OpLabel
               OpReturn
               OpFunctionEnd

(this was produced by using spirv-reduce on an glslang compiled OGL fragment shader)

error (minimized):

mlir-translate: mlir/include/mlir/IR/UseDefLists.h:198: mlir::IRObjectWithUseList<mlir::BlockOperand>::~IRObjectWithUseList() [OperandType = mlir::BlockOperand]: Assertion `use_empty() && "Cannot destroy a value that still has uses!"' failed.
Stack dump:
...
#<!-- -->12  mlir::Block::erase() Block.cpp:0:0
#<!-- -->13  mlir::spirv::Deserializer::structurizeControlFlow() Deserializer.cpp:0:0
#<!-- -->14  mlir::spirv::Deserializer::processFunctionEnd(llvm::ArrayRef&lt;unsigned int&gt;) Deserializer.cpp:0:0
#<!-- -->15  mlir::spirv::Deserializer::processFunction(llvm::ArrayRef&lt;unsigned int&gt;) Deserializer.cpp:0:0
#<!-- -->16  mlir::spirv::Deserializer::deserialize() Deserializer.cpp:0:0
#<!-- -->17  mlir::spirv::deserialize(llvm::ArrayRef&lt;unsigned int&gt;, mlir::MLIRContext*, mlir::spirv::DeserializationOptions const&amp;) Deserialization.cpp:0:0

[llvmbot]

@llvm/issue-subscribers-mlir-spirv

Author: alex_s168 (alex-s168)

On LLVM `d81ffd4ebb45` (latest main at time of writing)

mlir-translate --deserialize-spirv on the input below causes an error error:

; SPIR-V
; Version: 1.0
; Generator: Khronos SPIR-V Tools Assembler; 0
; Bound: 14
; Schema: 0
               OpCapability Shader
          %1 = OpExtInstImport "GLSL.std.450"
               OpMemoryModel Logical GLSL450
               OpEntryPoint Fragment %2 "main"
               OpExecutionMode %2 OriginLowerLeft
       %void = OpTypeVoid
          %4 = OpTypeFunction %void
       %bool = OpTypeBool
      %false = OpConstantFalse %bool
          %2 = OpFunction %void None %4
          %7 = OpLabel
               OpBranch %8
          %9 = OpLabel
               OpSelectionMerge %10 None
               OpBranchConditional %false %11 %11
         %11 = OpLabel
               OpBranch %12
         %12 = OpLabel
               OpBranch %10
         %13 = OpLabel
               OpBranch %12
         %10 = OpLabel
               OpBranch %8
          %8 = OpLabel
               OpReturn
               OpFunctionEnd

(this was produced by using spirv-reduce on an glslang compiled glsl fragment shader)

error (minimized):

mlir-translate: mlir/include/mlir/IR/UseDefLists.h:198: mlir::IRObjectWithUseList<mlir::BlockOperand>::~IRObjectWithUseList() [OperandType = mlir::BlockOperand]: Assertion `use_empty() && "Cannot destroy a value that still has uses!"' failed.
Stack dump:
...
#<!-- -->12  mlir::Block::erase() Block.cpp:0:0
#<!-- -->13  mlir::spirv::Deserializer::structurizeControlFlow() Deserializer.cpp:0:0
#<!-- -->14  mlir::spirv::Deserializer::processFunctionEnd(llvm::ArrayRef&lt;unsigned int&gt;) Deserializer.cpp:0:0
#<!-- -->15  mlir::spirv::Deserializer::processFunction(llvm::ArrayRef&lt;unsigned int&gt;) Deserializer.cpp:0:0
#<!-- -->16  mlir::spirv::Deserializer::deserialize() Deserializer.cpp:0:0
#<!-- -->17  mlir::spirv::deserialize(llvm::ArrayRef&lt;unsigned int&gt;, mlir::MLIRContext*, mlir::spirv::DeserializationOptions const&amp;) Deserialization.cpp:0:0

[kuhar]

@IgWod-IMG do you want to take a look?

[IgWod-IMG]

@kuhar I'm happy to have a look, I've seen related problems before

[IgWod-IMG]

So, the control flow is a bit weird. Most of the graph is unreachable from the entry block and there is a conditional branch going to the same block. Looking at the SPIR-V code above you get --- %7 is the entry block:

graph TD;
    **%7**-->%8;
    %9-->%11;
    %9-->%11;
    %11-->%12;
    %12-->%10;
    %10-->%8;
    %13-->%12

Loading

Now I suspect that the original CFG is less weird and this is the result of spirv-reduce. With this example I can see that the structurizer will struggle because it will try to put everything between selection header (%9) and selection merge (%10) into a region, but then since (%10) is not on the path from the header it won't be sunk, leaving it hanging and trying to point to the middle of a region (not valid MLIR) --- or something along those lines. Also I'm not sure how well unreachable control-flow is handled. The main point is that, unless I missed something, this is unstructured control flow.

At the moment we primarily support a structured control flow. If your original shader is unstrucutred (e.g., it has early-exists), it won't work (see #138688). A workaround for that is to pass --spirv-structurize-control-flow=false (see #140561) into mlir-translate, but depending on your use case it may cause some issues with the rest of the tooling.

Anyway, if you think that your control-flow is structured and can provide another example (without a dangling nodes) it would be easier to investigate. In the hindsight we should have a better way to communicate those errors to users.

[kuhar]

We shouldn't crash on any input IR, even if it's contrived. We can error out gracefully though if it's not something we want to support.

[IgWod-IMG]

Agreed, leave it with me and I'll work on the fix to make it more robust.

[alex-s168]

okay it appears like it was unstructured control flow.
I didn't know about --spirv-structurize-control-flow=false, that works for my application.
I agree that it should produce a better error message

also I subscribed to the "Region-based control-flow with early exits" RFC