[llvm-dev] Google’s TensorFlow team would like to contribute MLIR to the LLVM Foundation

Mehdi Amini via llvm-dev llvm-dev at lists.llvm.org
Mon Sep 9 15:57:46 PDT 2019


On Mon, Sep 9, 2019 at 12:30 PM Renato Golin <rengolin at gmail.com> wrote:

> Overall, I think it will be a good move.
>
> Maintenance wise, I'm expecting the existing community to move into
> LLVM (if not all in already), so I don't foresee any additional costs.
>
> Though, Hal's points are spot on...
>
> On Mon, 9 Sep 2019 at 18:47, Finkel, Hal J. via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> >  3. As a specific example of the above, the current development of the
> new Flang compiler depends on MLIR.
>
> Who knows, one day, Clang can, too! :)
>
> >  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).
>
> Yes, and yes! MLIR can become a simpler entry point into LLVM, from
> other languages, frameworks and optimisation plugins. A more abstract
> representation and a more stable IR generation from it, could make
> maintenance of external projects much easier than direct connections
> of today. This could benefit research as much as enterprise, and by
> consequence, the LLVM project.
>
>
Thanks for the great summary, this is exactly my view as well!


> > 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.
>
> Right, I'm also worried that it's too broad in respect to what it can
> do on paper, versus what LLVM can handle on code.
>
> With MLIR as a separate project, that point is interesting, at most.
> When it becomes part of the LLVM umbrella, then we need to make sure
> that MLIR and LLVM IR interact within known boundaries and expected
> behaviour.
>
> I'm not saying MLIR can't be used for anything else after the move,
> just saying that, by being inside the repo, and maintained by our
> community, LLVM IR would end up as the *primary* target, and there
> will be a minimum stability/functionality requirements.
>

I fully agree with everything you wrote! :)
I really hope that MLIR can succeed as an enabler for users to plug into
the LLVM ecosystem.

As an example of something that MLIR is trying to solve elegantly on top of
LLVM is helping with heterogeneous computing.
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.

This is still a work in progress, but if you look at this IR:
https://github.com/tensorflow/mlir/blob/master/test/mlir-cuda-runner/gpu-to-cubin.mlir#L6-L11

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).

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).

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.

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.
In the meantime we are currently still revamping our online tutorial in the
coming weeks (
https://github.com/tensorflow/mlir/blob/master/g3doc/Tutorials/Toy/Ch-1.md)
to make it more representative.

Hope this helps.

-- 
Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190909/e57e38a9/attachment.html>


More information about the llvm-dev mailing list