<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">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>
<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>