<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 19, 2015 at 9:48 AM, Neil Henning <span dir="ltr"><<a href="mailto:llvm@duskborn.com" target="_blank">llvm@duskborn.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Answers to Owen;<span class=""><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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>
</blockquote>
Why does that motivate it being a target?  Intrinsics do not have to be linked to a target.<br>
</blockquote></span>
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.</blockquote><div><br></div><div>It actually sort of makes sense to have them somewhere more generic. If you imagine a GPU driver based on LLVM, where the flow is SPIR-V -> LLVM IR -> GPU backend, then these intrinsics actually *are* going to filter down into a backend other than a "SPIR-V backend".</div><div><br></div><div>So we have at least two use cases:</div><div><br></div><div>1)</div><div>Frontend -> LLVM IR -> SPIR-V: primary concern is for the Frontend to generate LLVM IR that contains a subset of operations suitable for SPIR-V.</div><div><br></div><div>2)</div><div>SPIR-V -> LLVM IR -> GPU backend: primary concern is just deserializing the darn thing. Want lib/SPIRV to just be a simple (and fast and no security vulnerabilities!) way to suck in a buffer of SPIR-V and turn it into a Module.</div><div><br></div><div>It seems that we're getting pretty hung up on whether something in lib/Target is necessary for various random pieces of machinery for 1). E.g. in 1) are we compiling with a "spirv triple"? (is something in lib/Target needed for this?)</div><div>In 2) we are definitely not compiling with a spirv triple (actually I wonder how that will work: when will the triple and datalayout and stuff get changed...; during the deserialization process?).</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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>
</blockquote>
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>
</blockquote></span>
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.<br>
<br>
As Chris said;<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
There are two different things going on here:<br>
<br>
1) Where the code lives in the llvm tree.<br>
2) How clang and other tools expose it to users.<br>
<br>
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.<br>
</blockquote>
<br></span>
Is exactly what I thought we'd end up with.<span class=""><font color="#888888"><br>
<br>
-Neil.</font></span><div class=""><div class="h5"><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>
</div></div></blockquote></div><br></div></div>