• Advertisement
Sign in to follow this  

LLVM-SPIRV Instruction Mapping

This topic is 664 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm in the progress of writing the llvm backend for a shading language, and I'm slightly confused on how to handle the instruction mapping. I've had success on mapping the types (Which is fairly simple), but so far I've had to play the guessing games a bit for the instructions. Now this is mostly my fault, since I'm new to the llvm scene, but some examples (Which I cant seem to find) on instruction mapping in the SPIRV-LLVM project would be fantastic.

 

From the (Rather short) wiki:

Some SPIR-V instructions which can be included in basic blocks do not have corresponding LLVM instructions or intrinsics. These SPIR-V instructions are represented by function calls in LLVM. The function corresponding to a SPIR-V instruction is termed SPIR-V builtin function and its name is IA64 mangled with extensions for SPIR-V specific types. The unmangled name of a SPIR-V builtin function follows the convention

 

__spirv_{OpCodeName}{_OptionalPostfixes}
 

where {OpCodeName} is the op code name of the SPIR-V instructions without the "Op" prefix, e.g. EnqueueKernel. {OptionalPostfixes} are optional postfixes to specify decorations for the SPIR-V instruction. The SPIR-V op code name and each postfix does not contain "_".

SPIR-V builtin functions accepts all argument types accepted by the corresponding SPIR-V instructions. The literal operands of extended instruction are mapped to function call arguments with type i32.

 

So as described above, the unmangled name for an implicit lod sampling instruction would look as following I believe:

    __spirv_ + str(OpImageSampleImplicitLod) + _SomeOptionalPostFixes

 

And then I assume I would have to mangle this name into some internal id? Either way, I feel like I'm in the dark here because of my lack of experience and would love some assistence about the instruction mapping!

 

Thank you for your time.

Edited by Migi0027 (????)

Share this post


Link to post
Share on other sites
Advertisement

I'm not sure if it's going to help, but check this project out ( although I suppose you may be already familiar with it ):

 

https://github.com/KhronosGroup/SPIRV-LLVM

 

Also look at SPIRV-Cross project. It may be a help too, although its purpose is little different.

 

I should have explained myself better, that's exactly what I'm using. I've successfully compiled a bunch of programs to spirv (Through the llvm branch you linked), however I'm having some issues about mapping the instructions, and I was wondering if someone had some experience?  :)

 

But thanks!

Share this post


Link to post
Share on other sites

You may want to check out the Khronos keynote from the IWOCL conference: https://www.khronos.org/developers/library/2016-iwocl - specifically slide 9

 

LLVM is an ever evolving SDK for building compilers, which makes it very difficult to standardize against.  Khronos is using SPIR-V as the interchange format between your shader tool chain and the driver.  How the SPIR-V was produced is left up to the developer and how SPIR-V is consumed is up the API implementer.  Khronos is not describing how to use LLVM to produce SPIR-V.

 

Khronos does, indeed, acknowledge that LLVM is very powerful software and uses it in its own tool chains, as you have found with SPIRV-LLVM.  The caveat is that the LLVM IR and metadata format used in these tools is an internal interface and may change at any time (and frequently does!).  You are more then welcome to dig in and use LLVM-SPIRV in your LLVM tool chain; just be aware that you'll have to really dig in to figure out the internal interface for the snapshot you are currently looking at.

 

Hope this helps!

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement