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

Nicholas Wilson via llvm-dev llvm-dev at lists.llvm.org
Mon May 1 03:02:03 PDT 2017


> On 1 May 2017, at 4:28 pm, Bekket McClane <bekket.mcclane at gmail.com> wrote:
> 
> Great job Nicholas!
> 

Thanks! I want to get this in so I don’t have to maintain a separate version for my work on LDC, the LLVM D Compiler.

> Actually one of the topics in the OpenCL BoF during EuroLLVM is to discuss about whether we should put SPIRV as one of the LLVM backends. Some of the guys in ARM and Codeplay participate that BoF.

Great, any help (especially by those who actually know what they doing when it come to LLVM backends, i.e. not me ;) ) is greatly appreciated. Co-ordination will be the key to getting this done in a reasonable timeframe.

> Although there is no concrete conclusion, I think your work would be a valuable materials for folks in both Khronos and LLVM to determine whether put SPIRV under lib/Target. 

I think SPIRV should be a proper target (and therefore live in $ROOT/lib/Target) for a number of reasons.

1) Logically it is a target: it produces binary code and is the last stage in the compilation pipeline.

2) it makes it easier for consumers (LDC, clang) to set up the build system / CMake as they only need specify they wish to target SPIRV rather than specify they want to link to libLLVMSPIRV.a with some CMake hackery. This was part of the reason for making it a target, as I was unable to get LDC’s build system to pull in the required library from Khronos’ SPIRV-LLVM.

3) it will integrate much better into consumers existing consumers compilation pipelines, as for LDC, there were, until I made it a target, some rather ugly hacks to fit it in with the rest of the codebase that was setup to just pass the IR to a backend.

4) if its a target then it will stay up to date with LLVM and not stagnate fall many releases behind.

There are probably some others I am missing.

> Also, though I haven’t inspect your work in detail. I think you can take NVPTX and WebAssembly as reference instead of RISCV or SPARC, since the former two targets are both virtual targets, (unlimited amount of registers etc.), just like SPIRV. 

Haha, you overestimate my exposure to the LLVM codebase by a large margin.
 I used RISCV and SPARC because they are simple and I have very little idea what I’m doing, e.g. not knowing what files I need in order to make a backend (LLVMBuild.txt’s CMakeLists.txt,target info MCDesc etc.) no knowledge of the tablegen format (I’m still probably doin' it wrong), not because of architectural similarity. 

I have taken some Inspiration from NVPTX simply because my work on LDC involves GPUs in general, but thank for the tip anyway.

Nic






More information about the llvm-dev mailing list