<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">joker.eph@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid 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:1px solid 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:1px solid 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:1px solid 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:1px solid 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><br></div><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:1px solid 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:1px solid 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:1px solid 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:1px solid 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><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><div></div></div></div>