<div dir="ltr">I agree with Owen here, this is really just a serialization of llvm IR that may or may not support various LLVM IR features. Can you give another example of something not legal in SPIR that is legal in LLVM IR that you'd still be able to/want to lower?<div><br></div><div>(Bonus points, a serialization option that includes new LLVM IR features under a "next version" of SPIR :)<br><div><br></div><div>-eric</div></div></div><br><div class="gmail_quote">On Tue, May 19, 2015 at 8:35 AM Owen Anderson <<a href="mailto:resistor@mac.com">resistor@mac.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On May 19, 2015, at 1:25 AM, Neil Henning <<a href="mailto:llvm@duskborn.com" target="_blank">llvm@duskborn.com</a>> wrote:<br>
><br>
> 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’.<br>
<br>
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.<br>
<br>
> 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),<br>
<br>
Why does that motivate it being a target?  Intrinsics do not have to be linked to a target.<br>
<br>
> 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).<br>
<br>
Again, why does that motivate it being a target?  No amount of legalization can define away fundamentally unsupported major constructs.<br>
<br>
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.<br>
<br>
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.<br>
<br>
—Owen<br>
<br>
<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div>