Passing pointers to Input memory with Phi nodes triggers compilation failure

[Hugobros3]

The following snippet fails to compile with level-zero, but it's clearly an underlying compiler issue. I'm not sure if there is an easy way to run igc offline... Anyhow, I've bisected the problem to the OpPhi of type _ptr_Input_v3uint - removing it makes this compile just fine.

               OpCapability Kernel
               OpCapability Addresses
               OpCapability Int64
               OpCapability Linkage
               OpMemoryModel Physical64 OpenCL
               OpDecorate %7 Aliased
               OpDecorate %8 Aliased
               OpDecorate %gl_GlobalInvocationID BuiltIn GlobalInvocationId
       %uint = OpTypeInt 32 0
%_ptr_CrossWorkgroup_uint = OpTypePointer CrossWorkgroup %uint
       %void = OpTypeVoid
          %5 = OpTypeFunction %void %_ptr_CrossWorkgroup_uint %_ptr_CrossWorkgroup_uint
     %v3uint = OpTypeVector %uint 3
%_ptr_Input_v3uint = OpTypePointer Input %v3uint
%gl_GlobalInvocationID = OpVariable %_ptr_Input_v3uint Input
%_ptr_Input_uint = OpTypePointer Input %uint
     %uint_0 = OpConstant %uint 0
%_mem__pu32_ = OpTypeStruct %uint
      %ulong = OpTypeInt 64 0
  %copy_krnl = OpFunction %void None %5
          %7 = OpFunctionParameter %_ptr_CrossWorkgroup_uint
          %8 = OpFunctionParameter %_ptr_CrossWorkgroup_uint
%copy_krnl_0 = OpLabel
               OpBranch %cont
       %cont = OpLabel
       ; this opphi is problematic, if we replace %12 by %gl_GlobalInvocationID and comment it out, things work just fine
         %12 = OpPhi %_ptr_Input_v3uint %gl_GlobalInvocationID %copy_krnl_0
         %16 = OpAccessChain %_ptr_Input_uint %12 %uint_0
         %17 = OpLoad %uint %16
         %20 = OpBitcast %uint %17
         %21 = OpPtrAccessChain %_ptr_CrossWorkgroup_uint %7 %20
         %22 = OpLoad %uint %21 Aligned 4
         %23 = OpPtrAccessChain %_ptr_CrossWorkgroup_uint %8 %20
               OpStore %23 %22 Aligned 4
               OpReturn
               OpFunctionEnd

[bashbaug]

FWIW, this example passes through spirv-val, but it fails in the SPIR-V LLVM Translator.

The stack trace for the failure is (note: if you want to match up line numbers, this is built from the llvm_release_180 branch):

#5  0x00007ffff14f1c1f in llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) () from /lib/x86_64-linux-gnu/libLLVM-18.so.18.1
#6  0x0000555555786961 in SPIRV::replaceUsesOfBuiltinVar (V=0x555555ef6ca0, AccumulatedOffset=..., ReplacementFunc=0x555555f19678, GV=0x555555ef6ca0)
    at /home/bashbaug/git/SPIRV-LLVM-Translator-in-tree/llvm/projects/SPIRV-LLVM-Translator/lib/SPIRV/SPIRVUtil.cpp:2043
#7  0x0000555555786d38 in SPIRV::lowerBuiltinVariableToCall (GV=0x555555ef6ca0, Kind=spv::BuiltInGlobalInvocationId) at /home/bashbaug/git/SPIRV-LLVM-Translator-in-tree/llvm/projects/SPIRV-LLVM-Translator/lib/SPIRV/SPIRVUtil.cpp:2086
#8  0x0000555555786e1e in SPIRV::lowerBuiltinVariablesToCalls (M=0x555555e9cbf0) at /home/bashbaug/git/SPIRV-LLVM-Translator-in-tree/llvm/projects/SPIRV-LLVM-Translator/lib/SPIRV/SPIRVUtil.cpp:2096
#9  0x000055555578783e in SPIRV::lowerBuiltins (BM=0x555555ef4cc0, M=0x555555e9cbf0) at /home/bashbaug/git/SPIRV-LLVM-Translator-in-tree/llvm/projects/SPIRV-LLVM-Translator/lib/SPIRV/SPIRVUtil.cpp:2176
#10 0x0000555555686948 in SPIRV::SPIRVToLLVM::translate (this=0x7fffffffd0d0) at /home/bashbaug/git/SPIRV-LLVM-Translator-in-tree/llvm/projects/SPIRV-LLVM-Translator/lib/SPIRV/SPIRVReader.cpp:3606
#11 0x00005555556917f3 in llvm::convertSpirvToLLVM (C=..., BM=..., Opts=..., ErrMsg="") at /home/bashbaug/git/SPIRV-LLVM-Translator-in-tree/llvm/projects/SPIRV-LLVM-Translator/lib/SPIRV/SPIRVReader.cpp:5183
#12 0x0000555555691b3b in llvm::readSpirv (C=..., Opts=..., IS=..., M=@0x7fffffffd428: 0x3000000003, ErrMsg="") at /home/bashbaug/git/SPIRV-LLVM-Translator-in-tree/llvm/projects/SPIRV-LLVM-Translator/lib/SPIRV/SPIRVReader.cpp:5219
#13 0x000055555564b10c in convertSPIRVToLLVM (Opts=...) at /home/bashbaug/git/SPIRV-LLVM-Translator-in-tree/llvm/projects/SPIRV-LLVM-Translator/tools/llvm-spirv/llvm-spirv.cpp:395
#14 0x000055555564f4e4 in main (Ac=3, Av=0x7fffffffdda8) at /home/bashbaug/git/SPIRV-LLVM-Translator-in-tree/llvm/projects/SPIRV-LLVM-Translator/tools/llvm-spirv/llvm-spirv.cpp:823

The "Illegal use of a SPIR-V builtin variable" is due to the phi instruction:

(gdb) p U->dump()
  %4 = phi ptr addrspace(7) [ @__spirv_BuiltInGlobalInvocationId, %2 ]

I think we need to discuss on https://github.com/KhronosGroup/SPIRV-Registry/issues/291 whether this SPIR-V module really is valid. If it is, we will need changes to the SPIR-V LLVM Translator. If it isn't, we ought to enhance the SPIR-V validator.