<div dir="ltr">Hi Chris-<div><br></div><div>Can you add better memory disambiguation to the benefits? May be in terms of better memory dependency analysis OR better alias analysis.</div><div><br></div><div>thanks,</div><div>-Prashanth</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 21, 2020 at 8:33 AM Chris Lattner <<a href="mailto:clattner@nondot.org">clattner@nondot.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">Hi Prashanth,<div><br></div><div>I’m presenting a talk next Wednesday at CGO’20 about MLIR, and will be talking about some “how and why could clang and llvm use mlir” concepts.   I already hope to cover:</div><div><br></div><div>-  better separation of concerns in general.</div><div>- Make abi lowering be clang-independent</div><div>- Share OpenMP lowering across frontends, enable better openmp optimization (e.g. constant folding and hoisting across parallel loops is trivial)</div><div>- enabling high level optimizations (e.g. insert std::vector::reserve calls based on data flow analysis)</div><div>- Merging the clang CFG representation into the main flow</div><div><br></div><div>I’ll also mention some of the benefits of moving LLVM IR to MLIR - including things like multithreaded compilation, better location tracking, better modeling of invoke and other terminators, etc.</div><div><br></div><div>If anyone has any other specific things you’d like me to mention, please let me know!  I’ll be happy to share the slides with this list after the talk.  Thanks!</div><div><br></div><div>-Chris<br><div><br><blockquote type="cite"><div>On Feb 20, 2020, at 3:54 AM, Prashanth N R via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:</div><br><div><div dir="ltr">Thanks David for good design pointers. We are thinking about the design issues and we will look into it soon.<div><br></div><div>-Prashanth</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 18, 2020 at 4:36 PM David Chisnall via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">[ Dropping llvm-dev, because this seems to be entirely a discussion <br>
about clang ]<br>
<br>
On 16/02/2020 11:03, Nicolai Hähnle via cfe-dev wrote:<br>
> On Sun, Feb 16, 2020 at 10:22 AM Prashanth N R via llvm-dev<br>
> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>  wrote:<br>
>>>    Starting from May-June, we at "Compiler Tree" would  start porting clang compiler to use MLIR as middle end target. If someone has already started a similar effort we would love to collaborate with them. If someone would like to work with us, we are ready to form a group and collaborate. If there are sharing opportunities from Fortran side, we would like to consider the same.\<br>
> That's a rather vague statement, considering the flexibility of MLIR.<br>
> Could you explain your plans in more detail, and what specifically you<br>
> hope to achieve with them?<br>
<br>
I agree.  There are several possible goals here and the approach that <br>
makes sense will vary.  For example, if you just want to unify OpenMP <br>
support between clang and f18.  This could be accomplished by <br>
mechanically translating the LLVM builder calls to builder calls for the <br>
LLVM IR embedding in MLIR and adding the other OpenMP-specific parts. <br>
There are a few more complex things that I can imagine being of value:<br>
<br>
1. Embedding enough [Objective-]C[++] high-level semantic information in <br>
a new MLIR dialect that the static analyser can operate on this <br>
representation and it can then be lowered to LLVM IR.<br>
<br>
2. Embedding the full C (or even C++) type system in MLIR such that <br>
other front ends can target a C ABI and reuse clang's MLIR -> LLVM IR <br>
lowering pass to incorporate ABI-specific details.<br>
<br>
3. Deferring C++ and Objective-C dynamic dispatch lowering until later <br>
to retain more source-level type information for devirtualization or <br>
more precise CFI implementations.<br>
<br>
These are the first things that pop into my head and each one imposes a <br>
different set of requirements on the MLIR dialect that you'll be <br>
lowering to (though it's also possible to imagine a superset that <br>
supports all of these use cases).<br>
<br>
David<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>
_______________________________________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br></div></blockquote></div><br></div></div></blockquote></div>