[LLVMdev] [RFC] Upstreaming LLVM/SPIR-V converter

[Neil Henning]

Answers to Owen;
>> There are things in SPIR-V that are not representable by the LLVM IR, so we'd have to add SPIR-V specific intrinsics for this (again making the case for having it as a target more palatable),
> Why does that motivate it being a target?  Intrinsics do not have to be linked to a target.
My motivation here is that a target would give us a nice logical 
separation - EG. these intrinsics only work with the SPIR-V target and 
there is no way you should be calling them from any other context. I 
really didn't think people would want us to add a bunch of intrinsics to 
Intrinsics.td.
>> and also there are things in the IR that won't be allowed when producing SPIR-V (off the top of my head, in a graphics shader with logical addressing mode a ton of pointer use is banned).
> Again, why does that motivate it being a target?  No amount of legalization can define away fundamentally unsupported major constructs.
>
> More generally,  making it a target immediately invokes a lot of behavior that is undesirable for a serialization format between a fronted and a backend.  You don’t *want* LLVM to do a lot of wacky CodeGenPrepare and/or lowering before emitting SPIR-V, which is likely to lose source-level information that the eventual consumer wanted to have available.  You do not want to leverage any of the general target architecture.
>
> I really don’t see any strong reason for it to be a target at all, and all the use cases I can see for it are exactly the same as the use cases for LLVM bitcode, with a  “for graphics” qualifier tacked on.
My idea was that this would be backend ala the CppBackend, it would 
essentially just be a ModulePass that calls the lib/SPIRV/*Writer.cpp 
code. The 'backend' in this context is purely so that we can then enable 
Clang to target SPIR-V in the same consistent manner to all the other 
targets it supports.

As Chris said;

> There are two different things going on here:
>
> 1) Where the code lives in the llvm tree.
> 2) How clang and other tools expose it to users.
>
> Per #1, it is pretty clear to me that this is a serialization format and should be structured like the bitcode reader & writer.  It is not a target, though maybe it also need a minimal target (but not instruction selection tables etc) so that clang and other tools can generate code for it.

Is exactly what I thought we'd end up with.

-Neil.