<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 3, 2021 at 7:05 AM James Y Knight <<a href="mailto:jyknight@google.com">jyknight@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 2, 2021 at 6:46 PM Mehdi AMINI <<a href="mailto:joker.eph@gmail.com" target="_blank">joker.eph@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 2, 2021 at 3:18 PM James Y Knight <<a href="mailto:jyknight@google.com" target="_blank">jyknight@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 2, 2021 at 4:40 PM Mehdi AMINI via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Tue, Mar 2, 2021 at 3:07 AM Trifunovic, Konrad via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
A very good question. I was actually expecting it 😊<br>
<br>
So, at the moment, it does not integrate into MLIR SPIRV backend and we have not thought about it. I guess You are referring to having a SPV dialect in MLIR and using a 'serialize' option to produce a SPIR-V binary?<br>
<br>
I agree that developing two backends in parallel is a bit redundant. If SPIR-V LLVM backend becomes a production quality it means actually it could consume any LLVM IR (provided it does conform to some SPIR-V restrictions).<br>
By any LLVM IR input I mean: it should be irrelevant whether it is produced by a clang, MLIR to LLVM IR lowering or just some other front-end that produces LLVM IR.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
The biggest 'impedance mismatch' that I currently see is that SPV MLIR dialect is now targeted mostly at Vulkan, while LLVM SPIR-V backend targets compute. Besides instruction set, the fundamental difference is a memory model.<br>
So if we want to unify those, we should actually make SPIR-V LLVM backend able to produce Vulkan dialect of SPIR-V as well.<br>
<br>
My answer is a bit elusive, but I totally agree with Your proposal: we should work towards having a one solution, and, LLVM SPIR-V backend seems like a more universal one (since it sits lower in the compiler stack).<br>
My proposal would be to include some MLIR -> LLVM-IR translated code in the testing so to have this final goal in mind.<br></blockquote><div><br></div><div><div style="color:rgb(0,0,0)">Something you're missing here, and maybe Lei clarified but I'll reiterate: the SPIRV dialect in MLIR is equivalent to what your GlobalISel pass will produce. It can actually round-trip to/from the SPIRV binary format. So it is sitting lower than your backend in my view.</div><div style="color:rgb(0,0,0)">I can't figure out a situation where it would make sense to go from MLIR SPIRV dialect to LLVM to use this new backend, but I may miss something here...</div><div style="color:rgb(0,0,0)"><br></div></div><div style="color:rgb(0,0,0)">It would be really great to find a common path here before duplicating a lot of the same thing in the lllvm-project monorepo, for example being able to target the MLIR dialect from GlobalISel, or alternatively converting the MIR to it right after would be an interesting thing to explore.</div><div style="color:rgb(0,0,0)">I haven't seen it, but there was a talk last Sunday on this topic: <a href="https://llvm.org/devmtg/2021-02-28/#vm1" target="_blank">https://llvm.org/devmtg/2021-02-28/#vm1</a></div><div style="color:rgb(0,0,0)"><span style="color:rgb(34,34,34)"></span></div></div></div></div></div></div></blockquote><div><br></div><div>This sort of problem seems like just one of those unfortunate consequences of MLIR being effectively an "LLVM IR 2.0 -- Generic Edition", but not yet actually layered underneath LLVM where it really wants to be.</div></div></div></blockquote><div><br></div><div>I don't understand what you mean here with "layered underneath LLVM"? Can you elaborate on this?</div></div></div></blockquote><div><br></div><div>That ultimately the goal should be for LLVM IR to be a dialect of MLIR, and for much of the optimization and codegen processes in LLVM to be implemented as MLIR dialect lowering. Then, MLIR is foundational -- "layered" underneath LLVM's core -- LLVM would have a hard dependency on MLIR.</div></div></div></blockquote><div><br></div><div>OK I see what you mean now, I didn't connect to this because I think it is an open question whether we see this happen in this decade ;)</div><div><br></div><div>So my assumption coming here is that:</div><div>1) LLVM IR as it is now is "granted" (at least in the context of this thread).</div><div>2) A SPIRV backend that takes LLVMIR and use GlobalISel is desirable.</div><div><br></div><div>Considering this, my angle is mainly one of library, software engineering, and reuse / avoiding duplication.</div><div>So adding intrinsics to LLVM IR and improving the GPU support in LLVM IR is something I see as "obviously good" and necessary for this project. The only opportunity for sharing and avoiding duplication appears to me right after GlobalISel for the rest of the pipeline.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>At that point, SPIR-V as an MLIR dialect, and the SPIR-V backend doing MLIR dialect lowering would be effectively no different from how every target works -- just with a different output dialect.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> I think it doesn't really make sense to tie <i>this</i> project to those long-term goals of layering MLIR under LLVM-IR, given the extremely long timescale that is likely to occur in. The "proper" solution probably won't be possible any time soon.</div></div></div></blockquote><div><br></div><div>I'm not sure if we're talking about the same thing here: there is nothing that I suggest that would operate at the level of LLVM IR. And nothing that requires a "long timescale", it seems quite easily in scope to me here.</div></div></div></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>So, in the meantime, we could implement a special-case hack just for SPIRV, to enable lowering it to MLIR-SPIRV dialect. But, what's the purpose? It wouldn't really help move towards the longer term goal, I don't think? And if someone does need that at the moment, they can just feed the SPIRV binary format back into the existing MLIR SPIRV dialect, right?</div></div></div></blockquote><div><br></div><div>Do we want to maintain, in the LLVM monorepo, *two* different implementations of a SPIRV IR and associated serialization (and potential deserialization)? All the tools associated to manipulate it? I assume the backend may even want to implement optimization passes, are we gonna duplicate these as well?</div><div>(note that this isn't at the LLVM IR level, but post-instruction selection, so very ad-hoc to the backend anyway).0</div></div></div></blockquote><div><br></div><div>Quite possibly yes. It's unfortunate to have duplication, but given the current state of things, I think it should not be ruled out.</div><div><br></div><div>My inclination is that the following factors are likely to be true:</div><div>- The amount of code for SPIRV binary format serialization is not particularly large or tricky.</div><div></div><div>- The work to emit SPIR-V MLIR dialect from the LLVM SPIR-V backend will not be simpler than serializing to SPIR-V directly.</div><div>- Writing this custom code to emit SPIR-V MLIR dialect from the SPIR-V backend will not noticably further the longer-term goals of having LLVM core be implemented as MLIR dialect lowering.</div></div></div></blockquote><div><br></div><div>These are great considerations, I subscribe entirely :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div><div>It seems to me that the choice here is either writing new code in LLVM to emit the SPIR-V MLIR dialect in the GlobalISel SPIR-V backend, or new code in LLVM to emit SPIR-V directly. And while I find the long-term prospects of MLIR integration into LLVM extremely promising, using MLIR just as step-stone to MLIR SPIR-V serialization does not seem particularly interesting.</div><div><br></div><div>So, to me the interesting question is whether we'd expect to be doing something interesting after converting to the SPIR-V MLIR dialect form besides simply serializing to SPIR-V binary format. Something that would make the added complexity of serializing through MLIR seem more worthwhile. I guess I'm not immediately seeing this as likely to be the case, but it seems well worth further discussion.</div><div><br></div><div>A possibility you've mentioned is post-instruction-selection optimizations. Do you have something in particular in mind there?</div></div></div></div></blockquote><div><br></div><div>I suspect that post-Global ISel there is a bit more "than taking the MIR as-is and emit the SPIRV serialization in a single traversal". So converting MIR to MLIR means that everything that we want to happen at this point will be shared.</div><div>Note that this is different from other backends, because I don't expect SPIRV to share passes (RA, Scheduling, ...) on MIR or to take advantage of the MC layer in the same way (if I'm wrong here then my point is less strong though).</div><div><br></div><div>Cheers,</div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div></div></div>