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

[Chris Lattner via cfe-dev]

Hi Prashanth,

I’m presenting a talk next Wednesday at CGO’20 about MLIR, and will be talking about some “how and why could clang and llvm use mlir” concepts.   I already hope to cover:

-  better separation of concerns in general.
- Make abi lowering be clang-independent
- Share OpenMP lowering across frontends, enable better openmp optimization (e.g. constant folding and hoisting across parallel loops is trivial)
- enabling high level optimizations (e.g. insert std::vector::reserve calls based on data flow analysis)
- Merging the clang CFG representation into the main flow

I’ll also mention some of the benefits of moving LLVM IR to MLIR - including things like multithreaded compilation, better location tracking, better modeling of invoke and other terminators, etc.

If anyone has any other specific things you’d like me to mention, please let me know!  I’ll be happy to share the slides with this list after the talk.  Thanks!

-Chris

> On Feb 20, 2020, at 3:54 AM, Prashanth N R via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> Thanks David for good design pointers. We are thinking about the design issues and we will look into it soon.
> 
> -Prashanth
> 
> On Tue, Feb 18, 2020 at 4:36 PM David Chisnall via cfe-dev <cfe-dev at lists.llvm.org <mailto: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 <mailto: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
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
> _______________________________________________
> 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/20200220/f6709f1a/attachment.html>