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

[Jakob Bornecrantz via llvm-dev]

On Mon, May 1, 2017 at 12:02 PM, Nicholas Wilson via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>> On 1 May 2017, at 4:28 pm, Bekket McClane <bekket.mcclane at gmail.com> wrote:
>>
>> Great job Nicholas!
>>

Indeed this is great news!

>
> 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.
>

I want to mirror this comment, the fact that if I want use SPIR-V I
need to versions of my compiler made me just drop the idea of adding
support for it.

>> 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.

While I can't really comment on where in the code it should live. But
with my frontend developer hat I'll like say it should be treated as
much as possible as a target, at least as long as I can use the C-API
to get the C binary from a module that I have generated I am happy.

Cheers, Jakob.