I'm using the translator to compile LLVM with OpenCL intrinsics into SPIR-V for use with the oneAPI stack. My front-end is also using (mostly) typeless pointers, something that LLVM is probably going to switch to at some point in the future. Calls to e.g. atomic_add using i32 data look as follow:
This in turn makes the Intel compiler choke, because it doesn't have a definition for __builtin_spirv_OpAtomicIAdd_p1i8_i32_i32_i32() (due to the i8 in there).
Shouldn't the translator ignore the input pointer type and bitcast it, since it knows what the actual type should be from the atomic intrinsic? I guess this would need to happen anyway when pointers become typeless in some distant future.
I'm using the translator to compile LLVM with OpenCL intrinsics into SPIR-V for use with the oneAPI stack. My front-end is also using (mostly) typeless pointers, something that LLVM is probably going to switch to at some point in the future. Calls to e.g.
atomic_add
using i32 data look as follow:Unmangled, this is
atomic_add(int volatile CLglobal*, int)
.In the emitted SPIR-V code, it looks like the OpAtomicIAdd has retained the meaningless (typelss pointer)
i8
:This in turn makes the Intel compiler choke, because it doesn't have a definition for
__builtin_spirv_OpAtomicIAdd_p1i8_i32_i32_i32()
(due to thei8
in there).Shouldn't the translator ignore the input pointer type and bitcast it, since it knows what the actual type should be from the atomic intrinsic? I guess this would need to happen anyway when pointers become typeless in some distant future.