<div dir="ltr">Hi,<div><br></div><div>I actively working on LLVM project with SPIR (no V here), and would love to see SPIR-V get integrated into LLVM.</div><div><br></div><div>Does this SPIR-V "backend" support reading SPIR-V and generate LLVM IR in-memory representation?</div><div><br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 1, 2017 at 6:44 PM, Nicholas Wilson via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>
> On 2 May 2017, at 8:48 am, Tom Stellard <<a href="mailto:tstellar@redhat.com">tstellar@redhat.com</a>> wrote:<br>
> You would probably need to write a new tablegen backend to generate<br>
> instruction tables that would be used outside of LLVM.<br>
<br>
</span>I think I need to write one anyway because I need to generate lots of tables other than the instruction table (there are no registers and therefore no register table), at least one for each subsection of section 3 of the spec and then some. Wether or not it is inside or outside of LLVM is irrelevant. What is, is that I’m not sure that the same can be said for intrinsics, which will enable the removal of the mangling hacks. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
>> I am in the process of trying to make it “more traditional” where possible and it makes sense to do so, but I do not fully understand the backend pipeline and am just trying to express the intrinsics and binary format with tablegen at the moment. Regardless of the actual transformation pipeline used I think it should go in target for the advantages stated above, and the one that I missed was, it has its own target triples! Also IIRC the Mill CPUs will/(do?) only use one or two of the backend passes and I can’t imagine them not being considered targets.<br>
>><br>
><br>
> A "more traditional" backend is more than just using tablegen to generate<br>
> the instruction definitions.  It means implementing an instruction selector<br>
> and using SelectionDAG and MachineInstrs.  What I'm saying is that<br>
> SPIR-V is not a good fit for the existing infrastructure, so I think<br>
> it would be good to consider alternatives before going to far down that path.<br></span></blockquote><div>Not sure if the GlobalISel[1] allow us to skip some of the boring ISelDAG/legalization things. In this case we maybe able to generate SPIR-V from GlobalISel's generic Machine IR and by pass all those instruction selection/legalization things?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
<br>
</span>Indeed, tablegen is the first step. I intend to incorporate as much of the standard pipeline as makes sense (e.g. no register allocation because there are no registers). As I have said I know very little about the backend pipeline so I can’t comment a whole lot. Is SelectionDAG matching pieces of the IR and choosing instruction from them? Because I definitely want to do that, if it is a thing (the tablegen files are currently dag free and do not inherit from `Instruction` because I do not understand that process, I am merely transcribing the spec), any information is welcome.<br></blockquote><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
> I think we may be using different definitions of driver in this case.<br>
> From the perspective of LDC, it doesn't seem like it would matter<br>
> much if LLVM IR -> SPIR-V were in the LLVM tree or outside of it.<br>
> In both cases you have a library that takes LLVM IR as input and<br>
> produces SPIR-V as output.<br>
><br>
> -Tom<br>
<br>
</span>My point is that it is duplicated effort (i.e. one for LDC, one for clang and so on), and is redundant if it is a proper target. I am willing to put in the effort to allay concerns regarding the pipelining and legalisation, but I am steadfast in my opinion that it should be a target unless the benefits of not being a target can be shown to outweigh those of being a target.<br></blockquote><div><br></div><div>Alternatively:</div><div>Since SPIR-V is very close to LLVM IR, it may be a bad idea to translate LLVM IR to machine IR then to SPIR-V, direct LLVM IR/SPIR-V translation maybe simpler.</div><div> </div><div>In this case, we consider SPIR-V as an IO format instead of a backend. we can introduce a special IR writer and IR reader that write SPIR-V from LLVM IR in-memory representation and read SPIR-V to generated LLVM IR in-memory representation. This is also not hard to integrate into clang/opt and I had done similar things (not SPIR-V though)</div><div><br></div><div>In this case, it will be opt that read and generate SPIR-V, instead of llc.</div><div>This allow us to read SPIR-V into the pass pipeline and optimize them.</div><div><br></div><div>Thanks</div><div>Hongbin</div><div><br></div><div> [1]<a href="http://llvm.org/docs/GlobalISel.html">http://llvm.org/docs/GlobalISel.html</a></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div></div>