[cfe-dev] [llvm-dev] MLIR for clang

[Mehdi AMINI via cfe-dev]

On Tue, Feb 18, 2020 at 3:06 AM David Chisnall via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> [ Dropping llvm-dev, because this seems to be entirely a discussion
> about clang ]
>
> On 16/02/2020 11:03, Nicolai Hähnle via cfe-dev wrote:
> > On Sun, Feb 16, 2020 at 10:22 AM Prashanth N R via llvm-dev
> > <llvm-dev at lists.llvm.org>  wrote:
> >>>    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.\
> > That's a rather vague statement, considering the flexibility of MLIR.
> > Could you explain your plans in more detail, and what specifically you
> > hope to achieve with them?
>
> I agree.  There are several possible goals here and the approach that
> makes sense will vary.  For example, if you just want to unify OpenMP
> support between clang and f18.  This could be accomplished by
> mechanically translating the LLVM builder calls to builder calls for the
> LLVM IR embedding in MLIR and adding the other OpenMP-specific parts.
> There are a few more complex things that I can imagine being of value:
>
> 1. Embedding enough [Objective-]C[++] high-level semantic information in
> a new MLIR dialect that the static analyser can operate on this
> representation and it can then be lowered to LLVM IR.
>
> 2. Embedding the full C (or even C++) type system in MLIR such that
> other front ends can target a C ABI and reuse clang's MLIR -> LLVM IR
> lowering pass to incorporate ABI-specific details.
>

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).

-- 
Mehdi




>
> 3. Deferring C++ and Objective-C dynamic dispatch lowering until later
> to retain more source-level type information for devirtualization or
> more precise CFI implementations.
>
> These are the first things that pop into my head and each one imposes a
> different set of requirements on the MLIR dialect that you'll be
> lowering to (though it's also possible to imagine a superset that
> supports all of these use cases).
>
> David
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200218/93ee5dcf/attachment-0001.html>