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

[Nicholas Wilson via llvm-dev]

Thanks,

I’m still busy until the start of July (franticly writing my Honours thesis), but I’d be very interested in moving this forward after my thesis is handed in.


On 21 Jun 2017, at 5:41 am, Neil Hickey <Neil.Hickey at arm.com<mailto:Neil.Hickey at arm.com>> wrote:
Firstly, there are a number of benefits to having SPIR-V in LLVM as a backend, both to SPIR-V, the ecosystem and to LLVM.

 * Allows any frontend targeting llvm to also target SPIR-V
 * Improves robustness of open source tooling for SPIR-V
 * Single place for toolchain - People don't need to knit repositories together from multiple locations
 * Compatibility between LLVM and SPIR-V - As SPIR-V is integrated it will always track top of tree
 * We can create a target triple to subset what dialect of SPIR-V we are targeting
 * Using the aforementioned triple we can guide optimisations that take target information
 * Challenges of implementing SPIR-V backend can influence LLVM backend development, to improve LLVM usability by less conventional targets
 * Benefits LLVM by improving support for GPU code generation specifically

I'd also like to touch specifically on a point that I believe was originally made by Tom.

If the initial implementation of the SPIR-V backend went straight for GlobalISel and only GlobalISel then we would remove the need to worry about SelectionDAG and would remove some of the complexity from the translation step.

So as a proposal, could I suggest the following next steps?
1) Add a dummy SPIR-V target machine to llvm, replete with target triple
2) Implement an experimental backend making use of globalisel to target SPIR-V code generation
3) Add tests to verify correct execution

1) Should be doable by lifting files straight out of my fork of LLVM[1,2,3]. Probably a good idea to double check them, I had very little idea what I was doing when I wrote them. Also will need a separate for vulkan (currently spirvl, for SPIRV logical see non merge commits on the compute branch of [1])
3) I haven’t transferred the tests over from Khronos’ SPIRV-LLVM[4], but they will very likely need updating although sill a good starting point.
2) Sigh… this will require work.
Before figuring out what to copy verbatim across and what needs to use GlobalIsel, as the current implementation goes straight from the IR, please consider that using intrinsics is some thing I want to have happen, not the least of which is so I can kill of the mangling code and have proper windows support with LDC’s compilation pipeline (so the frontend doesn’t have to mangle some as Itanium and sone as MS C++).

I have a mostly complete SPIRV Core tablegen files[2], although it currently lacks a tablegen backend for itself, still required would be the instruction extension sets for OpenCL and Vulkan. N.B. they are constructed from the pdfs of the spec not the machine readable json, it has way less useful information w.r.t the intricacies for the format.

If anyone with knowledge of tablegen wants to get the tablegen files working that would be great. Also any work on the extension instruction sets would be very much appriciated, warning: its mind numbingly boring.

[1] LLVM https://github.com/thewilsonator/llvm
[2]  the SPIR-V target https://github.com/thewilsonator/llvm-target-spirv
[3] the interconversion command line utility https://github.com/thewilsonator/llvm-tool-spirv
[4] https://github.com/KhronosGroup/SPIRV-LLVM

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170621/811c8309/attachment.html>