Re: MLIR for clang

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: MLIR for clang

suyash singh via cfe-dev
+cfe-dev

On Sun, Feb 16, 2020 at 2:46 PM Prashanth N R <[hidden email]> 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.

   We are in the early phase of design for "C" part of the work. From our experience with (FC+MLIR) compiler, we are estimating that we would have an early cut of the compiler working with non-trivial workload within a quarter of starting of work.

  Please ping me for any queries or concerns. 

Regards,
-Prashanth

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] MLIR for clang

suyash singh via cfe-dev
Hi Prashanth,

On Sun, Feb 16, 2020 at 10:22 AM Prashanth N R via llvm-dev
<[hidden email]> 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?

Cheers,
Nicolai


>>
>>    We are in the early phase of design for "C" part of the work. From our experience with (FC+MLIR) compiler, we are estimating that we would have an early cut of the compiler working with non-trivial workload within a quarter of starting of work.
>>
>>   Please ping me for any queries or concerns.
>>
>> Regards,
>> -Prashanth
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev



--
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] MLIR for clang

suyash singh via cfe-dev
Currently LLVM uses a low level IR for representing programs. Memory disambiguation does not happen accurately for constructs like multi-dimensional arrays.  One of the ways we alleviate the same in LLVM currently is by using multiversioning of the code. By supporting a mid-level IR like MLIR we intend to keep the access indices of multidimensional array and do better disambiguation. 

thanks,
-Prashanth
 
On Sun, Feb 16, 2020 at 4:34 PM Nicolai Hähnle <[hidden email]> wrote:
Hi Prashanth,

On Sun, Feb 16, 2020 at 10:22 AM Prashanth N R via llvm-dev
<[hidden email]> 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?

Cheers,
Nicolai


>>
>>    We are in the early phase of design for "C" part of the work. From our experience with (FC+MLIR) compiler, we are estimating that we would have an early cut of the compiler working with non-trivial workload within a quarter of starting of work.
>>
>>   Please ping me for any queries or concerns.
>>
>> Regards,
>> -Prashanth
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev



--
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] MLIR for clang

suyash singh via cfe-dev
Fred Chow is a well known name in compiler community. He was the architect of Open64 compiler.  
His comment on LLVM IR from open64 mailing list can be seen at :  https://sourceforge.net/p/open64/mailman/message/23829398/ 
" From their name, LLVM roughly corresponds to Low WHIRL. I wonder how
LLVM tackles the compilation problems Open64 has tackled.  People with 
exposure to LLVM are welcome to chime in."



On Mon, Feb 17, 2020 at 10:43 PM Prashanth N R <[hidden email]> wrote:
Currently LLVM uses a low level IR for representing programs. Memory disambiguation does not happen accurately for constructs like multi-dimensional arrays.  One of the ways we alleviate the same in LLVM currently is by using multiversioning of the code. By supporting a mid-level IR like MLIR we intend to keep the access indices of multidimensional array and do better disambiguation. 

thanks,
-Prashanth
 
On Sun, Feb 16, 2020 at 4:34 PM Nicolai Hähnle <[hidden email]> wrote:
Hi Prashanth,

On Sun, Feb 16, 2020 at 10:22 AM Prashanth N R via llvm-dev
<[hidden email]> 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?

Cheers,
Nicolai


>>
>>    We are in the early phase of design for "C" part of the work. From our experience with (FC+MLIR) compiler, we are estimating that we would have an early cut of the compiler working with non-trivial workload within a quarter of starting of work.
>>
>>   Please ping me for any queries or concerns.
>>
>> Regards,
>> -Prashanth
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev



--
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] MLIR for clang

suyash singh via cfe-dev
When you actually start to solve and implement this you'll find that "LLVM IR" is actually mid-whirl on an almost 1:1 basis. (super close). However, we don't exactly do IR<>IR translation and instead hook in at an API level. So it's more matching constructs and trying to "get in where you fit in". Since we had overlapping mid-whirl optimizations we had to figure out which to turn on/off on each side.

We also skipped VH Whirl for a number of reasons and just kinda cut it out. I don't think Fred is subscribed to the list, but he isn't the only smart person who worked on the compiler. There were a few managers, brilliant people and unsung heroes who worked at SGI.

Dror Maydan and Sun Chan were more intimately involved with the actual implementation of loop optimizations iirc. Fred's best known for his low level codegen work and overall vision of compiler architecture.

On Tue, Feb 18, 2020 at 1:24 AM Prashanth N R via cfe-dev <[hidden email]> wrote:
Fred Chow is a well known name in compiler community. He was the architect of Open64 compiler.  
His comment on LLVM IR from open64 mailing list can be seen at :  https://sourceforge.net/p/open64/mailman/message/23829398/ 
" From their name, LLVM roughly corresponds to Low WHIRL. I wonder how
LLVM tackles the compilation problems Open64 has tackled.  People with 
exposure to LLVM are welcome to chime in."



On Mon, Feb 17, 2020 at 10:43 PM Prashanth N R <[hidden email]> wrote:
Currently LLVM uses a low level IR for representing programs. Memory disambiguation does not happen accurately for constructs like multi-dimensional arrays.  One of the ways we alleviate the same in LLVM currently is by using multiversioning of the code. By supporting a mid-level IR like MLIR we intend to keep the access indices of multidimensional array and do better disambiguation. 

thanks,
-Prashanth
 
On Sun, Feb 16, 2020 at 4:34 PM Nicolai Hähnle <[hidden email]> wrote:
Hi Prashanth,

On Sun, Feb 16, 2020 at 10:22 AM Prashanth N R via llvm-dev
<[hidden email]> 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?

Cheers,
Nicolai


>>
>>    We are in the early phase of design for "C" part of the work. From our experience with (FC+MLIR) compiler, we are estimating that we would have an early cut of the compiler working with non-trivial workload within a quarter of starting of work.
>>
>>   Please ping me for any queries or concerns.
>>
>> Regards,
>> -Prashanth
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev



--
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: MLIR for clang

suyash singh via cfe-dev
In reply to this post by suyash singh via cfe-dev

Hi, Prashanth,

I definitely recommend that we have a discussion first on design goals for this. You've mentioned modeling of multidimensional arrays, and I know you've also been thinking about OpenMP, and it would be good to lay out the desired end state.

Part of the reason I say this is because there are significant design decisions that I suspect will appear up front. Handling of multidimensional arrays is a good example. C/C++ certainly do have multidimensional arrays of static extent, but these are largely irrelevant for a significant fraction of production C++ use cases. This is because, in many cases, the array bounds are not known statically, or at least they're not all known statically, and so programmers make use of C++ wrapper libraries which provide the interface of multidimensional arrays implemented on top of one-dimensional heap-allocated data. If we create an infrastructure that works well for static multidimensional arrays but does not contain any provision for recognizing appropriate loop nests and also treating them using the multidimensional-array optimization infrastructure, we won't really improve the compiler in practice for many, if not most, relevant production users.

It's also going to be important what we optimize loops that only look like loops after coroutines are analyzed and inlined. Regardless, there certainly are areas in which we could do a better job optimizing constructs  (e.g., more devirtualization, optimization of exception handling and uses of RTTI), and it would be good to put everything out on the table so that decisions can be made based on use cases as opposed to being driven by the desire to use a particular tool.

Thanks again,

Hal

On 2/16/20 3:21 AM, Prashanth N R via cfe-dev wrote:
+cfe-dev

On Sun, Feb 16, 2020 at 2:46 PM Prashanth N R <[hidden email]> 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.

   We are in the early phase of design for "C" part of the work. From our experience with (FC+MLIR) compiler, we are estimating that we would have an early cut of the compiler working with non-trivial workload within a quarter of starting of work.

  Please ping me for any queries or concerns. 

Regards,
-Prashanth

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: MLIR for clang

suyash singh via cfe-dev
On 17 Feb 2020, at 13:27, Hal Finkel wrote:
> Hi, Prashanth,
>
> I definitely recommend that we have a discussion first on design goals
> for this. You've mentioned modeling of multidimensional arrays, and I
> know you've also been thinking about OpenMP, and it would be good to
> lay out the desired end state.

Is the goal for this to be an out-of-tree proof of concept, or is the
goal to eventually integrate this into LLVM and have Clang compile by
emitting MLIR as an intermediate stage?  The latter would be a huge
project with a lot of uncertain trade-offs, but I think it would be very
interesting; whereas I’m afraid the former is not something I can
spare any time to think about.

John.

>
> Part of the reason I say this is because there are significant design
> decisions that I suspect will appear up front. Handling of
> multidimensional arrays is a good example. C/C++ certainly do have
> multidimensional arrays of static extent, but these are largely
> irrelevant for a significant fraction of production C++ use cases.
> This is because, in many cases, the array bounds are not known
> statically, or at least they're not all known statically, and so
> programmers make use of C++ wrapper libraries which provide the
> interface of multidimensional arrays implemented on top of
> one-dimensional heap-allocated data. If we create an infrastructure
> that works well for static multidimensional arrays but does not
> contain any provision for recognizing appropriate loop nests and also
> treating them using the multidimensional-array optimization
> infrastructure, we won't really improve the compiler in practice for
> many, if not most, relevant production users.
>
> It's also going to be important what we optimize loops that only look
> like loops after coroutines are analyzed and inlined. Regardless,
> there certainly are areas in which we could do a better job optimizing
> constructs  (e.g., more devirtualization, optimization of exception
> handling and uses of RTTI), and it would be good to put everything out
> on the table so that decisions can be made based on use cases as
> opposed to being driven by the desire to use a particular tool.
>
> Thanks again,
>
> Hal
>
> On 2/16/20 3:21 AM, Prashanth N R via cfe-dev wrote:
>> +cfe-dev
>>
>> On Sun, Feb 16, 2020 at 2:46 PM Prashanth N R <[hidden email]
>> <mailto:[hidden email]>> 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.
>>
>>        We are in the early phase of design for "C" part of the
>> work.
>>     From our experience with (FC+MLIR) compiler, we are estimating
>>     that we would have an early cut of the compiler working with
>>     non-trivial workload within a quarter of starting of work.
>>
>>       Please ping me for any queries or concerns.
>>
>>     Regards,
>>     -Prashanth
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
> --
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] MLIR for clang

suyash singh via cfe-dev
In reply to this post by suyash singh via cfe-dev
[ 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
> <[hidden email]>  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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: MLIR for clang

suyash singh via cfe-dev
In reply to this post by suyash singh via cfe-dev
Hal-

Thanks for the critical  issues to ponder over. We will get back to you once we  have more clarity of the task. 

thanks,
-Prashanth

On Mon, Feb 17, 2020 at 11:57 PM Hal Finkel <[hidden email]> wrote:

Hi, Prashanth,

I definitely recommend that we have a discussion first on design goals for this. You've mentioned modeling of multidimensional arrays, and I know you've also been thinking about OpenMP, and it would be good to lay out the desired end state.

Part of the reason I say this is because there are significant design decisions that I suspect will appear up front. Handling of multidimensional arrays is a good example. C/C++ certainly do have multidimensional arrays of static extent, but these are largely irrelevant for a significant fraction of production C++ use cases. This is because, in many cases, the array bounds are not known statically, or at least they're not all known statically, and so programmers make use of C++ wrapper libraries which provide the interface of multidimensional arrays implemented on top of one-dimensional heap-allocated data. If we create an infrastructure that works well for static multidimensional arrays but does not contain any provision for recognizing appropriate loop nests and also treating them using the multidimensional-array optimization infrastructure, we won't really improve the compiler in practice for many, if not most, relevant production users.

It's also going to be important what we optimize loops that only look like loops after coroutines are analyzed and inlined. Regardless, there certainly are areas in which we could do a better job optimizing constructs  (e.g., more devirtualization, optimization of exception handling and uses of RTTI), and it would be good to put everything out on the table so that decisions can be made based on use cases as opposed to being driven by the desire to use a particular tool.

Thanks again,

Hal

On 2/16/20 3:21 AM, Prashanth N R via cfe-dev wrote:
+cfe-dev

On Sun, Feb 16, 2020 at 2:46 PM Prashanth N R <[hidden email]> 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.

   We are in the early phase of design for "C" part of the work. From our experience with (FC+MLIR) compiler, we are estimating that we would have an early cut of the compiler working with non-trivial workload within a quarter of starting of work.

  Please ping me for any queries or concerns. 

Regards,
-Prashanth

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] MLIR for clang

suyash singh via cfe-dev
In reply to this post by suyash singh via cfe-dev


On Tue, Feb 18, 2020 at 3:06 AM David Chisnall via cfe-dev <[hidden email]> 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
> <[hidden email]>  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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] MLIR for clang

suyash singh via cfe-dev
In reply to this post by suyash singh via cfe-dev
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 <[hidden email]> 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
> <[hidden email]>  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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] MLIR for clang

suyash singh 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 <[hidden email]> 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 <[hidden email]> 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
> <[hidden email]>  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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] MLIR for clang

suyash singh via cfe-dev
In reply to this post by suyash singh via cfe-dev
+1

This is a very big, long and complex task and if we don't take it as a community project, the off tree project will bit rot before it can be merged. It has happened so many times before and will certainly happen again if we're not careful.

Converting openmp and known library calls into memref and affine for would be super cool. 

Cheers, 
Renato 

On Mon, 17 Feb 2020, 18:27 Hal Finkel via llvm-dev, <[hidden email]> wrote:

Hi, Prashanth,

I definitely recommend that we have a discussion first on design goals for this. You've mentioned modeling of multidimensional arrays, and I know you've also been thinking about OpenMP, and it would be good to lay out the desired end state.

Part of the reason I say this is because there are significant design decisions that I suspect will appear up front. Handling of multidimensional arrays is a good example. C/C++ certainly do have multidimensional arrays of static extent, but these are largely irrelevant for a significant fraction of production C++ use cases. This is because, in many cases, the array bounds are not known statically, or at least they're not all known statically, and so programmers make use of C++ wrapper libraries which provide the interface of multidimensional arrays implemented on top of one-dimensional heap-allocated data. If we create an infrastructure that works well for static multidimensional arrays but does not contain any provision for recognizing appropriate loop nests and also treating them using the multidimensional-array optimization infrastructure, we won't really improve the compiler in practice for many, if not most, relevant production users.

It's also going to be important what we optimize loops that only look like loops after coroutines are analyzed and inlined. Regardless, there certainly are areas in which we could do a better job optimizing constructs  (e.g., more devirtualization, optimization of exception handling and uses of RTTI), and it would be good to put everything out on the table so that decisions can be made based on use cases as opposed to being driven by the desire to use a particular tool.

Thanks again,

Hal

On 2/16/20 3:21 AM, Prashanth N R via cfe-dev wrote:
+cfe-dev

On Sun, Feb 16, 2020 at 2:46 PM Prashanth N R <[hidden email]> 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.

   We are in the early phase of design for "C" part of the work. From our experience with (FC+MLIR) compiler, we are estimating that we would have an early cut of the compiler working with non-trivial workload within a quarter of starting of work.

  Please ping me for any queries or concerns. 

Regards,
-Prashanth

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] MLIR for clang

suyash singh via cfe-dev
In reply to this post by suyash singh 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> <[hidden email]>  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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] MLIR for clang

suyash singh via cfe-dev
In reply to this post by suyash singh via cfe-dev
Am Do., 20. Feb. 2020 um 21:04 Uhr schrieb Chris Lattner via cfe-dev
<[hidden email]>:

> 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!

If the flat CFG representation is only the first step, I'd be
interested in what what the end goal for representing
coroutines/if/while/do/for/switch statements would, especially in
combination with other statements such as
goto/continue/break/return/exceptions/destructors.

Michael
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] MLIR for clang

suyash singh via cfe-dev
I’ve added notes about these Michael and Prashanth! Thanks!

-Chris

> On Feb 22, 2020, at 6:19 PM, Michael Kruse <[hidden email]> wrote:
>
> Am Do., 20. Feb. 2020 um 21:04 Uhr schrieb Chris Lattner via cfe-dev
> <[hidden email]>:
>> 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!
>
> If the flat CFG representation is only the first step, I'd be
> interested in what what the end goal for representing
> coroutines/if/while/do/for/switch statements would, especially in
> combination with other statements such as
> goto/continue/break/return/exceptions/destructors.
>
> Michael

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] MLIR for clang

suyash singh via cfe-dev
Looking forward to your presentation.

Michael

Am Di., 25. Feb. 2020 um 16:24 Uhr schrieb Chris Lattner <[hidden email]>:

>
> I’ve added notes about these Michael and Prashanth! Thanks!
>
> -Chris
>
> > On Feb 22, 2020, at 6:19 PM, Michael Kruse <[hidden email]> wrote:
> >
> > Am Do., 20. Feb. 2020 um 21:04 Uhr schrieb Chris Lattner via cfe-dev
> > <[hidden email]>:
> >> 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!
> >
> > If the flat CFG representation is only the first step, I'd be
> > interested in what what the end goal for representing
> > coroutines/if/while/do/for/switch statements would, especially in
> > combination with other statements such as
> > goto/continue/break/return/exceptions/destructors.
> >
> > Michael
>
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] MLIR for clang

suyash singh via cfe-dev
Hi Michael (and others), here are the slides from the CGO presentation, please let us know if you have any questions!

-Chris


On Feb 25, 2020, at 3:03 PM, Michael Kruse <[hidden email]> wrote:

Looking forward to your presentation.

Michael

Am Di., 25. Feb. 2020 um 16:24 Uhr schrieb Chris Lattner <[hidden email]>:

I’ve added notes about these Michael and Prashanth! Thanks!

-Chris

On Feb 22, 2020, at 6:19 PM, Michael Kruse <[hidden email]> wrote:

Am Do., 20. Feb. 2020 um 21:04 Uhr schrieb Chris Lattner via cfe-dev
<[hidden email]>:
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!

If the flat CFG representation is only the first step, I'd be
interested in what what the end goal for representing
coroutines/if/while/do/for/switch statements would, especially in
combination with other statements such as
goto/continue/break/return/exceptions/destructors.

Michael



_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev