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

[Mehdi AMINI via llvm-dev]

On Tue, Sep 10, 2019 at 2:13 AM Renato Golin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Tue, 10 Sep 2019 at 06:49, Chris Lattner <clattner at google.com> wrote:
> > 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.
>
> Ah, the title was just "Flang update", I didn't check the abstract.
>

There are two talks about Flang, the one about MLIR is:
http://llvm.org/devmtg/2019-10/talk-abstracts.html#tech19

-- 
Mehdi



> Looking forward to it.
>
> > 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.
>
> Totally agreed!
>
> > 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.
>
> Absolutely.
>
> It doesn't make sense to put artificial orthogonal constraints, when
> we know the implementation would raise more questions than answer and
> could take years to get right. I'm hoping by adding MLIR first, we'd
> have a pretty solid use case and the eventual move by Clang, if any,
> would be smoother and more robust.
>
> I agree with this proposal being the first step. I'm also personally
> happy with the current level of docs and progress of Flang.
>
> LGTM, thanks! :D
>
> --renato
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190910/a4e81a14/attachment.html>