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

[Chris Lattner via llvm-dev]

Hi Renato,

Thank you for your kind words.  If you are interested, the documentation for MLIR is located here:
https://github.com/tensorflow/mlir/blob/master/g3doc/

Including a bunch of content, eg a full langref doc:
https://github.com/tensorflow/mlir/blob/master/g3doc/LangRef.md

-Chris

> On Sep 9, 2019, at 12:29 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.
> 
>> 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.
> 
> But perhaps more importantly, as Hal states clearly, is the need for
> an official specification, similar to the one for LLVM IR, as well as
> a formal document with the expected semantics into LLVM IR. Sooner,
> indeed.
> 
> cheers,
> --renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190909/b1fafe1b/attachment.html>