linking two spirvs produces with opaque ptrs fails

[airlied]

I'm not sure if this is here or spirv-tools but I'll start here.

Mesa has an intel_clc tool that is used to convert some CL kernels to intel gpu asm at build time. It wraps clang and spirv-llvm-translator and then does some spirv linking and reads it all into mesa NIR and the intel nir backend.

This fails at the moment due to opaque ptrs but I'm not sure how best to fix it:

# env MESA_SHADER_CACHE_DISABLE=true /builddir/build/BUILD/mesa-bd0d3c7b1c61e834e563f7f1c0c9ff553661cbd0/redhat-linux-build/src/intel/compiler/intel_clc -p dg2 --prefix gfx125_bvh_build_leaf_create_HW_instance_nodes -e create_HW_instance_nodes --in ../src/intel/vulkan/grl/gpu/bvh_build_leaf.cl --in /builddir/build/BUILD/mesa-bd0d3c7b1c61e834e563f7f1c0c9ff553661cbd0/src/intel/vulkan/grl/gpu/libs/lsc_intrinsics_fallback.cl -o src/intel/vulkan/grl/gfx125_bvh_build_leaf_create_HW_instance_nodes.h -- -cl-std=cl2.0 -D__OPENCL_VERSION__=200 -DMAX_HW_SIMD_WIDTH=16 -DMAX_WORKGROUP_SIZE=16 -I/builddir/build/BUILD/mesa-bd0d3c7b1c61e834e563f7f1c0c9ff553661cbd0/src/intel/vulkan/grl/gpu -I/builddir/build/BUILD/mesa-bd0d3c7b1c61e834e563f7f1c0c9ff553661cbd0/src/intel/vulkan/grl/include -include opencl-c.h (file=input,line=0,column=0,index=0): Type mismatch on symbol "store_uint4_L1WB_L3WB" between imported variable/function %77 and exported variable/function %9649.

this is because store_uint4_L1WB_L3WB in one unit,
%76 = OpTypeFunction %void %_ptr_CrossWorkgroup_struct_Quad %uint %v4uint

and the other
%1540 = OpTypeFunction %void %_ptr_CrossWorkgroup_v4uint %uint %v4uint

this is because the translator tries to work out from the caller what the correct type is
%arrayidx67 = getelementptr inbounds %struct.Quad, ptr addrspace(1) %1065, i64 %idxprom66 store ptr addrspace(1) %arrayidx67, ptr %dst, align 8 %1067 = load ptr addrspace(1), ptr %dst, align 8 %1068 = load <4 x i32>, ptr %pack0, align 16 call spir_func void @store_uint4_L1WB_L3WB(ptr addrspace(1) noundef %1067, i32 noundef 0, <4 x i32> noundef %1068) #8
but there is really no info to reconstruct that it wants a v4uint not a struct Quad

Anyone want to hazard a guess at where this could be solved?

[airlied]

@KhronosGroup/spir might give this a bit more audience.

[thesamesam]

See also:

• https://gitlab.freedesktop.org/mesa/mesa/-/issues/9701
• https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25536

[MrSidims]

Probably the best way is to introduce opaque pointers to SPIR-V, AFAIK that is work in progress. Compilers middle end should be having better knowledge of the types in the module after linking.

Unfortunately as you've said, there is not enough info for the translator to make a guess about the type of external global symbols. To double check, output from the translator is %1540 = OpTypeFunction %void %_ptr_CrossWorkgroup_v4uint %uint %v4uint , right?

Hacking SPIR-V linker also seem to be a bad idea. Is it possible to translate two modules in LLVM IR, then link them by llvm-link and translate back to SPIR-V?

[karolherbst]

Probably the best way is to introduce opaque pointers to SPIR-V, AFAIK that is work in progress. Compilers middle end should be having better knowledge of the types in the module after linking.

Unfortunately as you've said, there is not enough info for the translator to make a guess about the type of external global symbols. To double check, output from the translator is %1540 = OpTypeFunction %void %_ptr_CrossWorkgroup_v4uint %uint %v4uint , right?

Hacking SPIR-V linker also seem to be a bad idea. Is it possible to translate two modules in LLVM IR, then link them by llvm-link and translate back to SPIR-V?

it is, but we would rather not to. The point of using SPIR-V internally for all program objects was to get rid of needless overhead. Requiring to use llvm-link would basically require us to rewrite most of the program handling code.

It's kinda absurd to be in this situation, because regardless of what we do, how would one even generate valid spirv from the OpenCL C source code for linking through clang now? Is it simply impossible?

It also sounds absurd to add opaque pointers to SPIR-V simply to hack around limitations of llvm.

I guess one "solution" to this here would be that the translator always uses char * arguments for everything and always casts parameters to the proper type... it makes function parameters useless, but we are already in this situation with llvm anyway.