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

David Chisnall via cfe-dev cfe-dev at lists.llvm.org
Tue Feb 18 03:06:41 PST 2020

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

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


More information about the cfe-dev mailing list