<div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 10, 2019 at 2:13 AM Renato Golin via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On Tue, 10 Sep 2019 at 06:49, Chris Lattner <<a href="mailto:clattner@google.com" target="_blank">clattner@google.com</a>> wrote:<br>
> In all seriousness, if you didn’t notice, the Flang team is planning to give a talk at LLVMDev in a month or so about Flang + MLIR.  I’d also love to see a round table or other discussion about MLIR integration at the event.<br>
<br>
Ah, the title was just "Flang update", I didn't check the abstract.<br></blockquote><div><br></div><div>There are two talks about Flang, the one about MLIR is: <a href="http://llvm.org/devmtg/2019-10/talk-abstracts.html#tech19">http://llvm.org/devmtg/2019-10/talk-abstracts.html#tech19</a></div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Looking forward to it.<br>
<br>
> The topic of Clang generating MLIR is more sensitive and I think it is best broached as a separate conversation, one motivated with data.  I think that Clang generating MLIR can be a hugely positive thing (witness the explosion of recent proposals for LLVM IR extensions that are easily handled with MLIR) but it seems more conservative and logical to upgrade the existing Clang “CFG" representation to use MLIR first.  This brings simple and measurable improvements to the reliability, accuracy, and generality of the data flow analyses and the Clang Static Analyzer, without introducing a new step that could cause compile-time regressions.  Iff that goes well, we could consider the use of MLIR in the main compilation flow.<br>
<br>
Totally agreed!<br>
<br>
> In any case, I hope that "Clang adoption" is not considered to be a blocker for MLIR to be adopted as part of the LLVM project.  This hasn’t been a formal or historical requirement for new LLVM subprojects, and I’d like to make sure we don’t put undue adoption pressure on Clang - it is important that we are deliberate about each step and do the right (data driven) thing for the (huge) Clang community.<br>
<br>
Absolutely.<br>
<br>
It doesn't make sense to put artificial orthogonal constraints, when<br>
we know the implementation would raise more questions than answer and<br>
could take years to get right. I'm hoping by adding MLIR first, we'd<br>
have a pretty solid use case and the eventual move by Clang, if any,<br>
would be smoother and more robust.<br>
<br>
I agree with this proposal being the first step. I'm also personally<br>
happy with the current level of docs and progress of Flang.<br>
<br>
LGTM, thanks! :D<br>
<br>
--renato<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div></div>