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

[Prashanth N R via cfe-dev]

Hi Chris-

Can you add better memory disambiguation to the benefits? May be in terms
of better memory dependency analysis OR better alias analysis.

thanks,
-Prashanth

On Fri, Feb 21, 2020 at 8:33 AM Chris Lattner <clattner at nondot.org> wrote:

> 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> 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.
>>
>> 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
>>
> _______________________________________________
> 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/20200223/eb24f381/attachment.html>