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

[Owen Anderson]

> On May 19, 2015, at 1:25 AM, Neil Henning <llvm at duskborn.com> wrote:
> 
> The problem is - as Sean and Pete (and others before) have pointed out, from a users perspective they'll want to say 'clang make me SPIR-V’.

The *entire point* of my email was that that is only one of two use cases of SPIR-V.  As I said above, it’s a serialization format between a frontend and a backend, which means that for some clients it is an output format and for others it’s an input format.  It’s also likely that SPIR-V to SPIR-V translators will exist in the future.

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

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

—Owen