[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).
David
More information about the cfe-dev
mailing list