<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 18, 2020 at 3:06 AM David Chisnall via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-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">[ 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></blockquote><div><br></div><div>Personally I'm very interested in your second item: I just have too little bandwidth to look into this. But that is something in the back of my mind ever since I started working on MLIR (actually even long before).</div><div><br></div><div>-- </div><div>Mehdi</div><div><br></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">
<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></div>