<div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 9, 2019 at 12:30 PM Renato Golin <<a href="mailto:rengolin@gmail.com">rengolin@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">Overall, I think it will be a good move.<br>
<br>
Maintenance wise, I'm expecting the existing community to move into<br>
LLVM (if not all in already), so I don't foresee any additional costs.<br>
<br>
Though, Hal's points are spot on...<br>
<br>
On Mon, 9 Sep 2019 at 18:47, Finkel, Hal J. via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>  3. As a specific example of the above, the current development of the new Flang compiler depends on MLIR.<br>
<br>
Who knows, one day, Clang can, too! :)<br>
<br>
>  5. As a community, we have been moving toward increasing support for heterogeneous computing and accelerators (and given industry trends, I expect this to continue), and MLIR can facilitate that support in many cases (although I expect we'll see further enhancements in the core LLVM libraries as well).<br>
<br>
Yes, and yes! MLIR can become a simpler entry point into LLVM, from<br>
other languages, frameworks and optimisation plugins. A more abstract<br>
representation and a more stable IR generation from it, could make<br>
maintenance of external projects much easier than direct connections<br>
of today. This could benefit research as much as enterprise, and by<br>
consequence, the LLVM project.<br>
<br></blockquote><div><br></div><div>Thanks for the great summary, this is exactly my view as well!</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">
> That all having been said, I think that it's going to be very important to develop some documentation on how a frontend author looking to use LLVM backend technology, and a developer looking to implement different kinds of functionality, might reasonably choose whether to target or enhance MLIR components, LLVM components, or both. I expect that this kind of advice will evolve over time, but I'm sure we'll need it sooner rather than later.<br>
<br>
Right, I'm also worried that it's too broad in respect to what it can<br>
do on paper, versus what LLVM can handle on code.<br>
<br>
With MLIR as a separate project, that point is interesting, at most.<br>
When it becomes part of the LLVM umbrella, then we need to make sure<br>
that MLIR and LLVM IR interact within known boundaries and expected<br>
behaviour.<br>
<br>
I'm not saying MLIR can't be used for anything else after the move,<br>
just saying that, by being inside the repo, and maintained by our<br>
community, LLVM IR would end up as the *primary* target, and there<br>
will be a minimum stability/functionality requirements.<br></blockquote><div><br></div><div>I fully agree with everything you wrote! :)</div><div>I really hope that MLIR can succeed as an enabler for users to plug into the LLVM ecosystem.</div><div><br></div><div>As an example of something that MLIR is trying to solve elegantly on top of LLVM is helping with heterogeneous computing.</div><div>Today a compiler framework that would try to support a device accelerator (like a GPU) would need to manage outside of / above LLVM how to split the host and device computation. MLIR allows to have both in the same module, and providing some convenient facility for the "codegen" and integration with LLVM.</div><div><br></div><div>This is still a work in progress, but if you look at this IR: <a href="https://github.com/tensorflow/mlir/blob/master/test/mlir-cuda-runner/gpu-to-cubin.mlir#L6-L11">https://github.com/tensorflow/mlir/blob/master/test/mlir-cuda-runner/gpu-to-cubin.mlir#L6-L11</a><br><br>The lines I highlighted are defining a GPU kernel, wrapped in a "gpu.launch" operation. The `mlir-cuda-runner` is a command line tool that tests will run passes to separate the kernel GPU code from the host code, and emit the LLVM IR in two separate LLVM modules: one for the GPU kernel (using the NVPTX backend) and another one for the host. Then everything is ran through a JIT (assuming you have CUDA and a compatible GPU installed).</div><div><br></div><div><div>In the example above, LLVM is directly used for both the host and the kernel, but there is also a Vulkan/SPIR-V emitter (instead of NVPTX) in the work. In this case LLVM would be used for providing the JIT environment and for the host module, but not the kernel (at least not unless there is a SPIR-V backend in LLVM).</div><div></div></div><div><br></div><div>Fundamentally MLIR is very extensible, and let the user define their own abstraction and compose on top of whatever the community will want to propose in the core.</div><div><br></div><div>We proposed a tutorial for the US Dev Meeting in which we planned to show how this layers and compose with LLVM in detail, but there are already so many great tutorial sessions in the schedule that we couldn't get a slot.</div><div>In the meantime we are currently still revamping our online tutorial in the coming weeks (<a href="https://github.com/tensorflow/mlir/blob/master/g3doc/Tutorials/Toy/Ch-1.md">https://github.com/tensorflow/mlir/blob/master/g3doc/Tutorials/Toy/Ch-1.md</a>) to make it more representative.</div><div><br></div><div>Hope this helps.</div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div></div></div></div>