<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Prashanth,<div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">- better separation of concerns in general.</div><div class="">- Make abi lowering be clang-independent</div><div class="">- Share OpenMP lowering across frontends, enable better openmp optimization (e.g. constant folding and hoisting across parallel loops is trivial)</div><div class="">- enabling high level optimizations (e.g. insert std::vector::reserve calls based on data flow analysis)</div><div class="">- Merging the clang CFG representation into the main flow</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">-Chris<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Feb 20, 2020, at 3:54 AM, Prashanth N R via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Thanks David for good design pointers. We are thinking about the design issues and we will look into it soon.<div class=""><br class=""></div><div class="">-Prashanth</div></div><br class=""><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" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class=""></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">[ Dropping llvm-dev, because this seems to be entirely a discussion <br class="">
about clang ]<br class="">
<br class="">
On 16/02/2020 11:03, Nicolai Hähnle via cfe-dev wrote:<br class="">
> On Sun, Feb 16, 2020 at 10:22 AM Prashanth N R via llvm-dev<br class="">
> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class="">
>>> 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 class="">
> That's a rather vague statement, considering the flexibility of MLIR.<br class="">
> Could you explain your plans in more detail, and what specifically you<br class="">
> hope to achieve with them?<br class="">
<br class="">
I agree. There are several possible goals here and the approach that <br class="">
makes sense will vary. For example, if you just want to unify OpenMP <br class="">
support between clang and f18. This could be accomplished by <br class="">
mechanically translating the LLVM builder calls to builder calls for the <br class="">
LLVM IR embedding in MLIR and adding the other OpenMP-specific parts. <br class="">
There are a few more complex things that I can imagine being of value:<br class="">
<br class="">
1. Embedding enough [Objective-]C[++] high-level semantic information in <br class="">
a new MLIR dialect that the static analyser can operate on this <br class="">
representation and it can then be lowered to LLVM IR.<br class="">
<br class="">
2. Embedding the full C (or even C++) type system in MLIR such that <br class="">
other front ends can target a C ABI and reuse clang's MLIR -> LLVM IR <br class="">
lowering pass to incorporate ABI-specific details.<br class="">
<br class="">
3. Deferring C++ and Objective-C dynamic dispatch lowering until later <br class="">
to retain more source-level type information for devirtualization or <br class="">
more precise CFI implementations.<br class="">
<br class="">
These are the first things that pop into my head and each one imposes a <br class="">
different set of requirements on the MLIR dialect that you'll be <br class="">
lowering to (though it's also possible to imagine a superset that <br class="">
supports all of these use cases).<br class="">
<br class="">
David<br class="">
_______________________________________________<br class="">
cfe-dev mailing list<br class="">
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class="">
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="">
</blockquote></div>
_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a><br class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev<br class=""></div></blockquote></div><br class=""></div></body></html>