<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
FWIW: +1 from me. Personally, I am very excited about this.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
I cannot speak on behalf of Arm, but I haven't heard about any concerns either.<br>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> llvm-dev <llvm-dev-bounces@lists.llvm.org> on behalf of Chris Lattner via llvm-dev <llvm-dev@lists.llvm.org><br>
<b>Sent:</b> 09 September 2019 22:22<br>
<b>To:</b> Renato Golin <rengolin@gmail.com><br>
<b>Cc:</b> llvm-dev <llvm-dev@lists.llvm.org>; Reid Tatge <tatge@google.com>; Mehdi Amini <aminim@google.com>; Tatiana Shpeisman <shpeisman@google.com><br>
<b>Subject:</b> Re: [llvm-dev] Google’s TensorFlow team would like to contribute MLIR to the LLVM Foundation</font>
<div> </div>
</div>
<div dir="auto">Hi Renato,
<div><br>
</div>
<div>Thank you for your kind words.  If you are interested, the documentation for MLIR is located here:</div>
<div><a href="https://github.com/tensorflow/mlir/blob/master/g3doc/LangRef.md">https://github.com/tensorflow/mlir/blob/master/g3doc/</a></div>
<div><br>
</div>
<div>Including a bunch of content, eg a full langref doc:</div>
<div><a href="https://github.com/tensorflow/mlir/blob/master/g3doc/LangRef.md">https://github.com/tensorflow/mlir/blob/master/g3doc/LangRef.md</a><br>
<br>
<div id="x_AppleMailSignature" dir="ltr">
<div>-Chris</div>
</div>
<div dir="ltr"><br>
On Sep 9, 2019, at 12:29 PM, Renato Golin <<a href="mailto:rengolin@gmail.com">rengolin@gmail.com</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div dir="ltr"><span>Overall, I think it will be a good move.</span><br>
<span></span><br>
<span>Maintenance wise, I'm expecting the existing community to move into</span><br>
<span>LLVM (if not all in already), so I don't foresee any additional costs.</span><br>
<span></span><br>
<span>Though, Hal's points are spot on...</span><br>
<span></span><br>
<span>On Mon, 9 Sep 2019 at 18:47, Finkel, Hal J. via llvm-dev</span><br>
<span><<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:</span><br>
<blockquote type="cite"><span>3. As a specific example of the above, the current development of the new Flang compiler depends on MLIR.</span><br>
</blockquote>
<span></span><br>
<span>Who knows, one day, Clang can, too! :)</span><br>
<span></span><br>
<blockquote type="cite"><span>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).</span><br>
</blockquote>
<span></span><br>
<span>Yes, and yes! MLIR can become a simpler entry point into LLVM, from</span><br>
<span>other languages, frameworks and optimisation plugins. A more abstract</span><br>
<span>representation and a more stable IR generation from it, could make</span><br>
<span>maintenance of external projects much easier than direct connections</span><br>
<span>of today. This could benefit research as much as enterprise, and by</span><br>
<span>consequence, the LLVM project.</span><br>
<span></span><br>
<blockquote type="cite"><span>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.</span><br>
</blockquote>
<span></span><br>
<span>Right, I'm also worried that it's too broad in respect to what it can</span><br>
<span>do on paper, versus what LLVM can handle on code.</span><br>
<span></span><br>
<span>With MLIR as a separate project, that point is interesting, at most.</span><br>
<span>When it becomes part of the LLVM umbrella, then we need to make sure</span><br>
<span>that MLIR and LLVM IR interact within known boundaries and expected</span><br>
<span>behaviour.</span><br>
<span></span><br>
<span>I'm not saying MLIR can't be used for anything else after the move,</span><br>
<span>just saying that, by being inside the repo, and maintained by our</span><br>
<span>community, LLVM IR would end up as the *primary* target, and there</span><br>
<span>will be a minimum stability/functionality requirements.</span><br>
<span></span><br>
<span>But perhaps more importantly, as Hal states clearly, is the need for</span><br>
<span>an official specification, similar to the one for LLVM IR, as well as</span><br>
<span>a formal document with the expected semantics into LLVM IR. Sooner,</span><br>
<span>indeed.</span><br>
<span></span><br>
<span>cheers,</span><br>
<span>--renato</span><br>
</div>
</blockquote>
</div>
</div>
</body>
</html>