SPIRV code fails validation after optimization

[pborsutzki]

Hi,

I built a shader in slang that fails validation on -O3, but does not on -O1. The slang team redirected me here as they think the problem comes from spirv-opt.

Compiling the slang code from the slang ticket gives me shader.spv spirv file on -O0, find it here: spirv_opt.zip.

Calling spirv-val shader.spv from the 1.3.280 vulkan sdk gives me no validation errors for this file.

Calling spirv-opt --validate-after-all -O shader.spv -o shaderOpt.spv results in this validation error:

error: line 124: Expected Constituent type to be equal to the corresponding member type of Result Type struct
  %92 = OpCompositeConstruct %Bar %88 %121

error: line 0: Validation failed after pass simplify-instructions

Can you fix this issue or point me to a workaround? Thanks!

[cassiebeckley]

Minimal reproducible example:

; SPIR-V
; Version: 1.5
; Generator: Khronos; 40
; Bound: 91
; Schema: 0
               OpCapability Int64
               OpCapability VariablePointers
               OpCapability PhysicalStorageBufferAddresses
               OpCapability Shader
               OpExtension "SPV_KHR_storage_buffer_storage_class"
               OpExtension "SPV_KHR_variable_pointers"
               OpExtension "SPV_KHR_physical_storage_buffer"
               OpMemoryModel PhysicalStorageBuffer64 GLSL450
               OpEntryPoint GLCompute %2 "main"
               OpExecutionMode %2 LocalSize 1 1 1
               OpMemberDecorate %structA 0 Offset 0
               OpMemberDecorate %structB 0 Offset 0
               OpMemberDecorate %structC 0 Offset 0
       %void = OpTypeVoid
          %3 = OpTypeFunction %void
      %ulong = OpTypeInt 64 0
 %structA = OpTypeStruct %ulong
 %structB = OpTypeStruct %ulong
 %structC = OpTypeStruct %structB
         %90 = OpUndef %structA
          %2 = OpFunction %void None %3
          %4 = OpLabel
         %45 = OpCompositeExtract %ulong %90 0
         %40 = OpCompositeConstruct %structB %45
         %34 = OpCompositeConstruct %structC %40
               OpReturn
               OpFunctionEnd

[cassiebeckley]

Before and after simplify-instructions:

; IR before pass simplify-instructions
OpCapability Int64
OpCapability VariablePointers
OpCapability PhysicalStorageBufferAddresses
OpCapability Shader
OpExtension "SPV_KHR_storage_buffer_storage_class"
OpExtension "SPV_KHR_variable_pointers"
OpExtension "SPV_KHR_physical_storage_buffer"
OpMemoryModel PhysicalStorageBuffer64 GLSL450
OpEntryPoint GLCompute %1 "main"
OpExecutionMode %1 LocalSize 1 1 1
OpMemberDecorate %_struct_2 0 Offset 0
OpMemberDecorate %_struct_3 0 Offset 0
OpMemberDecorate %_struct_4 0 Offset 0
%void = OpTypeVoid
%6 = OpTypeFunction %void
%ulong = OpTypeInt 64 0
%_struct_2 = OpTypeStruct %ulong
%_struct_3 = OpTypeStruct %ulong
%_struct_4 = OpTypeStruct %_struct_3
%8 = OpUndef %_struct_2
%1 = OpFunction %void None %6
%9 = OpLabel
%10 = OpCompositeExtract %ulong %8 0
%11 = OpCompositeConstruct %_struct_3 %10
%12 = OpCompositeConstruct %_struct_4 %11
OpReturn
OpFunctionEnd

; IR before pass scalar-replacement=100
OpCapability Int64
OpCapability VariablePointers
OpCapability PhysicalStorageBufferAddresses
OpCapability Shader
OpExtension "SPV_KHR_storage_buffer_storage_class"
OpExtension "SPV_KHR_variable_pointers"
OpExtension "SPV_KHR_physical_storage_buffer"
OpMemoryModel PhysicalStorageBuffer64 GLSL450
OpEntryPoint GLCompute %1 "main"
OpExecutionMode %1 LocalSize 1 1 1
OpMemberDecorate %_struct_2 0 Offset 0
OpMemberDecorate %_struct_3 0 Offset 0
OpMemberDecorate %_struct_4 0 Offset 0
%void = OpTypeVoid
%6 = OpTypeFunction %void
%ulong = OpTypeInt 64 0
%_struct_2 = OpTypeStruct %ulong
%_struct_3 = OpTypeStruct %ulong
%_struct_4 = OpTypeStruct %_struct_3
%8 = OpUndef %_struct_2
%1 = OpFunction %void None %6
%9 = OpLabel
%10 = OpCompositeExtract %ulong %8 0
%12 = OpCompositeConstruct %_struct_4 %8
OpReturn
OpFunctionEnd

[s-perron]

This look like an issues with the isomorphic structs. This confuses the type manager when the type manager is not used correctly. This is a known source of bugs, but there is not enough activity on spirv-opt to make a major change to the type manager.

I'll try fixing the code in this one place, and check if I can add an assert that might catch some of these cases. Assuming my guess at the root cause is correct.