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

Owen Anderson
2015-05-19T15:30:51Z

> 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