Handling SPIRV LLVM translator-produced IR with duplicate names

[maleadt]

I was playing with spirv2clc in my LLVM-based toolflow, which relies on the SPIRV to LLVM translator to generate SPIR-V. For example, a simple kernel that returns nothing looks as follows in LLVM IR:

target triple = "spir64-unknown-unknown"

define spir_kernel void @_Z6kernel() {
  ret void
}

... which produces the following SPIR-V IR:

; SPIR-V
; Version: 1.0
; Generator: Khronos LLVM/SPIR-V Translator; 14
; Bound: 9
; Schema: 0
               OpCapability Addresses
               OpCapability Linkage
               OpCapability Kernel
          %1 = OpExtInstImport "OpenCL.std"
               OpMemoryModel Physical64 OpenCL
               OpEntryPoint Kernel %6 "_Z6kernel"
               OpSource Unknown 0
               OpName %_Z6kernel "_Z6kernel"
               OpDecorate %_Z6kernel LinkageAttributes "_Z6kernel" Export
       %void = OpTypeVoid
          %3 = OpTypeFunction %void
  %_Z6kernel = OpFunction %void None %3
          %5 = OpLabel
               OpReturn
               OpFunctionEnd
          %6 = OpFunction %void None %3
          %7 = OpLabel
          %8 = OpFunctionCall %void %_Z6kernel
               OpReturn
               OpFunctionEnd

The generated SPIR-V code here is peculiar, it looks like the spir_kernel attribute is handled by the translator by generating a wrapper entry-point calling the inner kernel. spirv2clc doesn't handle that very well, producing the following invalid OpenCL code:

void _Z6kernel(){
conversion:;
  return;
}
void kernel _Z6kernel(){
v7:;
  _Z6kernel();
  return;
}

<kernel>:5:6: warning: attribute declaration must precede definition
void kernel _Z6kernel(){
     ^
<kernel>:1:6: note: previous definition is here
void _Z6kernel(){
     ^
<kernel>:5:13: error: redefinition of '_Z6kernel'
void kernel _Z6kernel(){
            ^
<kernel>:1:6: note: previous definition is here
void _Z6kernel(){
     ^

[maleadt]

Hm, there doesn't seem to be an easy way around this.

• Both functions are generated, because it is illegal to have a function call to a kernel -> add an entry point wrapper around functions (llvm pass) KhronosGroup/SPIRV-LLVM-Translator#1149
• Because the module may be linked, it's impossible to tell if there may be an external call to the function -> Revert "Don't wrap kernels that are not being called in the module (#2119)" KhronosGroup/SPIRV-LLVM-Translator#2301

x-ref KhronosGroup/SPIRV-LLVM-Translator#2029