Mangling OpenCL/SPIR-V external declarations from frontends other than Clang

LLVM Project
, , ,
1

Hi all,

I was looking into lowering GPU kernels into SPIR-V and passing that to intel graphics compiler without the use of external SPIR-V translator. The exposed SPIR-V built-ins (e.g., __spirv_BuiltInWorkgroupSize) have to be mangled to be processed correctly by the underlying stack. Same goes to OpenCL C built-in function calls (like get_local_id). Those allow overloading and do not provide intrinsics (I found this old post on the topic SPIR - Built-ins and Name Mangling discussion).

The mangling scheme for both is basically Itanium (Khronos’ translator replicates the mangler with slight deviations), so putting the same code for mangling inside LLVM itself (currently it is in Clang) would be duplication. Using Clang’s mangler also doesn’t seem appealing for projects with a different frontend. And moving the mangler from Clang to LLVM sounds like a ton of work (and I expect a lot of “whys”).

So I wonder if this is the only use case. I’d expect custom frontends (I’m thinking MLIR) to want to be able to emit some external function calls and mangle them in certain cases like the one I encountered. Is it only OpenCL or are there any other scenarios that may benefit?

1 Like
2

Hi Petr,

Thanks for the post! The SPIR-V backend currently accepts unmangled calls to builtins in a very limited way. I added a pull request with some initial tests demonstrating this.

Theoretically all the currently defined builtins should be recognized this way right now. However, since the backend needs to recover pointer element types and uses the mangled strings for this (partially), some unmangled calls may not be lowered properly or may crash (e.g. unmangled-SampledImage-return-type.ll in the pull request). This is still the remaining logic from before the TargetExtType was added.

I will rework the SPIRVBuiltins.cpp file to use type information either from the TargetExtType or fall back to the expected types (which will be provided in the SPIRVBuiltins.td TableGen definitions). This should provide full support for unmangled builtin calls.

1 Like