llvm dev - May 2016 - Status of new pass manager work

Greetings folks,

I just wanted to post a brief update on the status of the new pass manager.
Philip asked me to do this at last month's social and Life intervened, but
he's still got a great point, so I wanted to get it out there with one day
to spare before he nagged me again. =D

I'll keep it very brief and high level. If folks have questions about
anything, happy to dig into it.

- The core framework is there. It works, and we even have CGSCC passes
using both Module and Function analyses with caching and everything. Yay!
We also have initial loop pass infrastructure thanks to Justin! Yay!

- The biggest missing piece of infrastructure IMO is communicating
invalidation information between two parts of the pass manager itself when
they are operating over the results of an analysis. Both the loop passes
and the CGSCC passes really need this. I'm currently working on this and
hope to finish the first cut at CGSCC stuff for this in a few days.

- The second biggest missing piece is a good system for managing sets of
related analyses for the purpose of invalidation. Justin and I have
discussed using designated enums that form sets, but there hasn't been a
lot of concrete progress here.

- Most of the rest is porting passes. Lots of folks have started to help
here which is great, but there is still likely room for help on this front.
Much of this is independent of the missing infrastructure fortunately. Some
good examples are GVN, SROA, and the LoopInfo passes. Fair warning, CGSCC
passes are *much* harder to port than others and interact with some of the
missing infrastructure. Other passes are much easier IMO.

There may be more that I'm missing, but hopefully this helps people have an
idea of where things are.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160505/eef2b6d7/attachment.html>

On Thu, May 5, 2016 at 1:29 AM, Chandler Carruth via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Greetings folks,
>
> I just wanted to post a brief update on the status of the new pass
> manager. Philip asked me to do this at last month's social and Life
> intervened, but he's still got a great point, so I wanted to get it out
> there with one day to spare before he nagged me again. =D
>
> I'll keep it very brief and high level. If folks have questions about
> anything, happy to dig into it.
>
> - The core framework is there. It works, and we even have CGSCC passes
> using both Module and Function analyses with caching and everything. Yay!
> We also have initial loop pass infrastructure thanks to Justin! Yay!
>
> - The biggest missing piece of infrastructure IMO is communicating
> invalidation information between two parts of the pass manager itself when
> they are operating over the results of an analysis. Both the loop passes
> and the CGSCC passes really need this. I'm currently working on this
and
> hope to finish the first cut at CGSCC stuff for this in a few days.
>
> - The second biggest missing piece is a good system for managing sets of
> related analyses for the purpose of invalidation. Justin and I have
> discussed using designated enums that form sets, but there hasn't been
a
> lot of concrete progress here.
>
Can we maybe just have a function for each "set"? e.g. you just call
`preserveAllCFGPasses(PA)`.
We can maybe stamp out `preserveAllCFGPasses` and any others from the .def
file to make sure there is a single point of truth.

-- Sean Silva

>
> - Most of the rest is porting passes. Lots of folks have started to help
> here which is great, but there is still likely room for help on this front.
> Much of this is independent of the missing infrastructure fortunately. Some
> good examples are GVN, SROA, and the LoopInfo passes. Fair warning, CGSCC
> passes are *much* harder to port than others and interact with some of the
> missing infrastructure. Other passes are much easier IMO.
>
> There may be more that I'm missing, but hopefully this helps people
have
> an idea of where things are.
>
> -Chandler
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160505/8635bc97/attachment.html>

On Thu, May 5, 2016 at 12:12 PM Sean Silva <chisophugis at gmail.com>
wrote:
> On Thu, May 5, 2016 at 1:29 AM, Chandler Carruth via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Greetings folks,
>>
>> I just wanted to post a brief update on the status of the new pass
>> manager. Philip asked me to do this at last month's social and Life
>> intervened, but he's still got a great point, so I wanted to get it
out
>> there with one day to spare before he nagged me again. =D
>>
>> I'll keep it very brief and high level. If folks have questions
about
>> anything, happy to dig into it.
>>
>> - The core framework is there. It works, and we even have CGSCC passes
>> using both Module and Function analyses with caching and everything.
Yay!
>> We also have initial loop pass infrastructure thanks to Justin! Yay!
>>
>> - The biggest missing piece of infrastructure IMO is communicating
>> invalidation information between two parts of the pass manager itself
when
>> they are operating over the results of an analysis. Both the loop
passes
>> and the CGSCC passes really need this. I'm currently working on
this and
>> hope to finish the first cut at CGSCC stuff for this in a few days.
>>
>> - The second biggest missing piece is a good system for managing sets
of
>> related analyses for the purpose of invalidation. Justin and I have
>> discussed using designated enums that form sets, but there hasn't
been a
>> lot of concrete progress here.
>>
>
> Can we maybe just have a function for each "set"? e.g. you just
call
> `preserveAllCFGPasses(PA)`.
> We can maybe stamp out `preserveAllCFGPasses` and any others from the .def
> file to make sure there is a single point of truth.
>
My preference would be to keep the participation in a set local to the
analysis implementation.

>
> -- Sean Silva
>
>
>>
>> - Most of the rest is porting passes. Lots of folks have started to
help
>> here which is great, but there is still likely room for help on this
front.
>> Much of this is independent of the missing infrastructure fortunately.
Some
>> good examples are GVN, SROA, and the LoopInfo passes. Fair warning,
CGSCC
>> passes are *much* harder to port than others and interact with some of
the
>> missing infrastructure. Other passes are much easier IMO.
>>
>> There may be more that I'm missing, but hopefully this helps people
have
>> an idea of where things are.
>>
>> -Chandler
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160505/aba1db1d/attachment.html>

Thank you for the update and for all the work on this!  Having the new 
pass manager in place will enable a lot of powerful follow on work.  
This type of major rearchitecting is often a thankless job, but it's 
very necessary.  I am really looking forward to this being done and on 
by default.

Philip

On 05/05/2016 01:29 AM, Chandler Carruth wrote:
> Greetings folks,
>
> I just wanted to post a brief update on the status of the new pass 
> manager. Philip asked me to do this at last month's social and Life 
> intervened, but he's still got a great point, so I wanted to get it 
> out there with one day to spare before he nagged me again. =D
>
> I'll keep it very brief and high level. If folks have questions about 
> anything, happy to dig into it.
>
> - The core framework is there. It works, and we even have CGSCC passes 
> using both Module and Function analyses with caching and everything. 
> Yay! We also have initial loop pass infrastructure thanks to Justin! Yay!
>
> - The biggest missing piece of infrastructure IMO is communicating 
> invalidation information between two parts of the pass manager itself 
> when they are operating over the results of an analysis. Both the loop 
> passes and the CGSCC passes really need this. I'm currently working on 
> this and hope to finish the first cut at CGSCC stuff for this in a few 
> days.
>
> - The second biggest missing piece is a good system for managing sets 
> of related analyses for the purpose of invalidation. Justin and I have 
> discussed using designated enums that form sets, but there hasn't been 
> a lot of concrete progress here.
>
> - Most of the rest is porting passes. Lots of folks have started to 
> help here which is great, but there is still likely room for help on 
> this front. Much of this is independent of the missing infrastructure 
> fortunately. Some good examples are GVN, SROA, and the LoopInfo 
> passes. Fair warning, CGSCC passes are *much* harder to port than 
> others and interact with some of the missing infrastructure. Other 
> passes are much easier IMO.
>
> There may be more that I'm missing, but hopefully this helps people 
> have an idea of where things are.
>
> -Chandler