<div dir="ltr"><div dir="ltr">On Wed, 3 Mar 2021 at 10:11, Trifunovic, Konrad <<a href="mailto:konrad.trifunovic@intel.com">konrad.trifunovic@intel.com</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">> With that said, I understand that software development has many reality concerns (like existing codebase, familiarity with different components, etc.) and we have many different use cases, which may mean that different paths make sense. So please don't take this as a negative feedback in general. It's just that to me it's unclear how we can unify here right now. Even when the time arrives for unification, I'd believe going through MLIR is better to have general SPIR-V support. :)<br>
<br>
A very good discussion! I seem to be overly optimistic at the first place at unifying those two approaches. Now I believe that we actually should have two paths, for the reasons You have just explained and for the reasons of supporting 'legacy' paths/compilers that rely on a classical, years old approach: Front-End -> LLVM-IR (opt) -> backend (llc). For that legacy path, a plain old 'backend' approach is still (in my view) the way to go. On the other hand, when MLIR evolves and gets wider adoption, it will be the way to go. From the semantic point of view, MLIR is much better suited for representing structured and extensible nature of SPIR-V. But for MLIR approach to be adopted, new languages/front-ends need to be aware of that structure, so to take most of the advantage of it. If Clang C/C++ start to use MLIR as its native generation format - that would be a big case for MLIR approach, but until that happens, we need to have some intermediate solution.</blockquote><div><br></div><div>I think there are two points here:</div><div><br></div><div>1. How many SPIRV end-points we have</div><div><br></div><div>This is mostly about software engineering concerns of duplication, maintenance, etc. But it's also about IR support, with MLIR having an upper hand here because of the existing implementation and its inherent flexibility with dialects.</div><div><br></div><div>It's perfectly fine to have two back-ends for a while, but since we moved MLIR to the monorepo, we need to treat it as part of the LLVM family, not a side project. </div><div><br></div><div>LLVM IR has some "flexibility" through intrinsics, which we could use to translate MLIR concepts that can't be represented in LLVM IR for the purpose of lowering only. Optimisations on these intrinsics would bring the usual problems.</div><div><br></div><div>2. Where do the optimisations happen in code lowering to SPIRV</div><div><br></div><div>I think Ronan's points are a good basis for keeping that in MLIR, at least for the current code. Now, if that precludes optimising in LLVM IR, than this could be a conflict with this proposal.</div><div><br></div><div>If the code passes through MLIR or not will be a decision of the toolchain, that will pick the best path for each workload. This allows us to have concurrent approaches in tree, but also makes it hard to test and creates corner cases that are hard to test.</div><div><br></div><div>So, while I appreciate this is a large proposal, that will likely take a year or more to get into shape, I think the ultimate goal (after the current proposal) should be that we end up with one back-end.</div><div><br></div><div>I'm a big fan of MLIR, and I think we should keep developing the SPIRV dialect and possibly this could be the entry point of all SPIRV toolchains. </div><div><br></div><div>While Clang will take a long time (if ever) to generate MLIR for C/C++, it could very well generate MLIR for non-C++ (OpenCL, OpenMP, SYCL, etc) which is then optimised, compiled into LLVM IR and linked to the main module (or not, for multi-targets) after high-level optimisations.</div><div><br></div><div>This would answer both questions above and create a pipeline that is consistent, easier to test and with lower overall maintenance costs.</div><div><br></div><div>cheers,</div><div>--renato</div></div></div>