[llvm-dev] [SPIR-V] SPIR-V in LLVM

Mon May 1 08:53:53 PDT 2017

On 05/01/2017 04:01 AM, Nicholas Wilson via llvm-dev wrote:
> I note that there was a talk recently at EuroLLVM SPIR-V and LLVM about and so I want to get this message out soon so as to avoid duplicated effort.
> 
> I have an up to date backend for SPIR-V on an up to date fork (~2-3 weeks behind) of LLVM, transplanted and “modernised” from Khronos’ SPIRV-LLVM that I plan on integrating into LLVM trunk. While it is usable in it’s current form there are several issues.
> 

Thanks for taking the initiative to work on this.  A well supported LLVM IR to SPIR-V
transformation layer is something that could be very useful.

> SPIRV-LLVM’s SPIRV support is not a real backend and does not live in /lib/Target/SPIRV. This has been solved, SPIRV is now a proper target(s). I have not copied the tests across yet, and they will need to be updated in light of the changes made/being made below.
> It only support’s the OpenCL “flavour” of SPIRV, but not the Vulkan. I plan on eventually supporting this but its priority is less than that of mainline integration.
> Intrinsics (for both Core and OpenCL extension instructions, Vulkan to follow) are done through C++ "Itanium with extensions” mangling. I plan to convert these to a table-gen format and cull the associated mangling code..
> Likewise the instruction format is currently done through a home-brew table format, which I am in the process of converting to table-gen. The core instructions are almost complete, but I haven’t started on the OpenCL instructions.
> As noted in the talk the textual representation is different from the the reference implementation. I see no advantage of the current format over the reference implementation’s format, infact theirs is much easier to read, This is a low priority.
> The instruction table-gen tables contain a significant number of critical non-instruction tables (there are no registers) and therefore a proper table-gen backend needs to be written to accomodate for this. Required.
> There are some LLVM “infrastructure” things (TargetInfo, MCTargetDesc) that I have stubs in order to get LLVM to compile, I have no idea what I’m doing and those were mostly adapted from Sparc and RISCV. Due to the lack of a Dyld and the fact that SPIR-V is  intermediate format, there is no point of a jit, Simple optimisations (CSE,DCE, some very simple inlining) would be nice to have, as would DebugInfo support.
> 
> The code is available at my GitHub: 
> SPIRV backend https://github.com/thewilsonator/llvm-target-spirv 
> LLVM https://github.com/thewilsonator/llvm/tree/compute 
> should you want to inspect/offer advice.
> 
> I am very busy until about July, but I just want to put this out here to gather interest / feedback / contributors.
> 

First of all you may want to review the thread from a few years ago about
putting a SPIR-V target into LLVM: 
http://llvm.1065342.n5.nabble.com/RFC-Proposal-for-Adding-SPIRV-Target-td82552.html

The fact that the SPIR-V target translates LLVM IR to SPIR-V directly and
does not use SelectionDAG/MachineInstrs or any of the standard lowering
mechanism is a strong case against having it in lib/Target.  There are
two solutions for this: have the code live outside of lib/Target or as an
out-of-tree project(maybe as part of SPIRV-Tools[1]) or rewrite it to use
the standard lowering mechanism of LLVM.

In my opinion, doing LLVM IR->SPIR-V directly is a better option than
trying to convert it to a proper LLVM target.  SPIR-V is too high level
to be able to gain any advantage from using LLVM's standard lowering
mechanism.

You will lose a lot of the type information going through the
SelectionDAG/MachineInstr layers, which is a major disadvantage.  Also,
since almost everything is legal in SPIR-V, you won't be getting the
same kind of advantages from it as other targets.

SPIR-V and LLVM IR are actually fairly similar in terms of what level of the
compiler stack the were designed for, so I think doing a simple
LLVM IR -> SPIR-V conversion will be the easiest and give you the best
results in the the end.

Also, if you are able to integrate it into SPIR-V Tools you will be able
to re-use the existing SPIR-V in memory representation and the
reader/writer APIs.

I realize that having a separate library will make this more difficult to
integrate into clang, but there are other targets that use external tools
for linking/assembling so, you may be able to find a way to write a SPIR-V
driver for clang that called out to this external tool for the
LLVM IR -> SPIR-V phase.

-Tom

[1] https://github.com/KhronosGroup/SPIRV-Tools

> Thanks,
> Nicholas Wilson
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 