llvm dev - Sep 2013 - [LLVMdev] Heads up: Pass Manager changes will be starting shortly

On Sat, Sep 14, 2013 at 3:57 PM, Reed Kotler <rkotler at mips.com> wrote:
> Hi Chandler,
>
> What changes are you planning to make?
>
> Are you going to submit a proposal and RFC?
>
There have been several RFCs...

What's your specific question?

I'm planning to essentially try to build a new pass management layer that
doesn't suffer from the problems the existing one does. I could describe
every interface I plan in prose and email it out, but I'm not sure
that's
really the most effective way to do it. My plan has been to work on
implementing the new system in-tree, and let folks code review it and pick
it apart as usual. When folks are happy with it, and it works, then we can
look at switching over.

>
> Reed
>
>
>
> On 09/14/2013 03:46 PM, Chandler Carruth wrote:
>
>> I just wanted to give everyone a head up. I'm starting work on the
pass
>> manager based on numerous list discussions and some IRC discussions.
>>
>> The first steps will be marking the existing code as "legacy"
and
>> clearing a path to build new facilities here. From there I'll start
>> building the new facilities without enabling them.
>>
>> Some explicit legacy support goals:
>>
>> 1) I'm going to build a bridge so that an existing Pass can be
inserted
>> into the new pass manager with some adaptors and everything will just
>> work. This may require touching the code that sets up the pass manager,
>> but not the code that defines a pass. This will work even once the new
>> pass manager bits are enabled if at all possible.
>>
>> 2) If you have code that includes the current PassManager headers,
>> nothing should break right away, but when the new manager
infrastructure
>> is enabled, I'll likely remove the old PassManager headers,
breaking
>> this code. My goal is to only break code that directly interacts with
>> the management layer.
>>
>> 3) I'm going to play namespace games so that we don't end up
with
>> PassManagerV2 and other silly names. The legacy headers will paper over
>> this to keep legacy code compiling without change.
>>
>> -Chandler
>>
>>
>> ______________________________**_________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>
http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130914/c47b8229/attachment.html>

On 09/14/2013 04:05 PM, Chandler Carruth wrote:
> On Sat, Sep 14, 2013 at 3:57 PM, Reed Kotler <rkotler at mips.com 
> <mailto:rkotler at mips.com>> wrote:
>
>     Hi Chandler,
>
>     What changes are you planning to make?
>
>     Are you going to submit a proposal and RFC?
>
>
> There have been several RFCs...
>
> What's your specific question?
>
Which RFCs cover this?

Will the new system allow for passes to be inserted dynamically after 
startup?

I have some delicate things that I did to make this ability to switch 
between mips 32 and mips16 ( they are different instruction sets) that 
relies on the pass manager working the way it does now. I'm not sure 
what you are planning to do and how it might affect what I did. It was 
very tricky to get that to work and a lot of things depend on it working 
now.

I don't think that we need to see how this will be implemented but I 
think that it would be helpful to list what you are trying to accomplish 
at a high level and what new features will be there and how the behavior 
will change from now.

> I'm planning to essentially try to build a new pass management layer 
> that doesn't suffer from the problems the existing one does. I could 
> describe every interface I plan in prose and email it out, but I'm not 
> sure that's really the most effective way to do it. My plan has been 
> to work on implementing the new system in-tree, and let folks code 
> review it and pick it apart as usual. When folks are happy with it, 
> and it works, then we can look at switching over.
>
>
>     Reed
>
>
>
>     On 09/14/2013 03:46 PM, Chandler Carruth wrote:
>
>         I just wanted to give everyone a head up. I'm starting work on
>         the pass
>         manager based on numerous list discussions and some IRC
>         discussions.
>
>         The first steps will be marking the existing code as
"legacy" and
>         clearing a path to build new facilities here. From there I'll
>         start
>         building the new facilities without enabling them.
>
>         Some explicit legacy support goals:
>
>         1) I'm going to build a bridge so that an existing Pass can be
>         inserted
>         into the new pass manager with some adaptors and everything
>         will just
>         work. This may require touching the code that sets up the pass
>         manager,
>         but not the code that defines a pass. This will work even once
>         the new
>         pass manager bits are enabled if at all possible.
>
>         2) If you have code that includes the current PassManager headers,
>         nothing should break right away, but when the new manager
>         infrastructure
>         is enabled, I'll likely remove the old PassManager headers,
>         breaking
>         this code. My goal is to only break code that directly
>         interacts with
>         the management layer.
>
>         3) I'm going to play namespace games so that we don't end
up with
>         PassManagerV2 and other silly names. The legacy headers will
>         paper over
>         this to keep legacy code compiling without change.
>
>         -Chandler
>
>
>         _______________________________________________
>         LLVM Developers mailing list
>         LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
>         http://llvm.cs.uiuc.edu
>         http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130914/3f37ad5d/attachment.html>

On Sat, Sep 14, 2013 at 4:15 PM, reed kotler <rkotler at mips.com> wrote:
>  On 09/14/2013 04:05 PM, Chandler Carruth wrote:
>
> On Sat, Sep 14, 2013 at 3:57 PM, Reed Kotler <rkotler at mips.com>
wrote:
>
>> Hi Chandler,
>>
>> What changes are you planning to make?
>>
>> Are you going to submit a proposal and RFC?
>>
>
>  There have been several RFCs...
>
>  What's your specific question?
>
>
> Which RFCs cover this?
>
The primary one was 'Pass Manager Redux', but over the past year the
planned design has shifted some. But not in ways that I think will impact
you at all.

>
> Will the new system allow for passes to be inserted dynamically after
> startup?
>
Yes.

>
> I have some delicate things that I did to make this ability to switch
> between mips 32 and mips16 ( they are different instruction sets) that
> relies on the pass manager working the way it does now. I'm not sure
what
> you are planning to do and how it might affect what I did. It was very
> tricky to get that to work and a lot of things depend on it working now.
>
As long as this is tested in the tree, it won't break.

>
> I don't think that we need to see how this will be implemented but I
think
> that it would be helpful to list what you are trying to accomplish at a
> high level and what new features will be there and how the behavior will
> change from now.
>
Sure. Some of this is covered in my RFC. Others will be covered with the
new code and documentation that explain the micro-level differences. Most
of the things that are different from the RFC are the obvious consequence
of me and others looking at how it would be implemented. That's why I want
to implement it before committing to a lot more details.

The flip side is that I'd like code review of my implementation in a
reasonable incremental manner, and so it is likely to go directly into the
tree, and merely be disabled. I think that's a reasonable path forward, and
it will still leave lots of time for discussion about the exact design and
implementation before we make any switch.

-Chandler

>
>
>
>   I'm planning to essentially try to build a new pass management layer
> that doesn't suffer from the problems the existing one does. I could
> describe every interface I plan in prose and email it out, but I'm not
sure
> that's really the most effective way to do it. My plan has been to work
on
> implementing the new system in-tree, and let folks code review it and pick
> it apart as usual. When folks are happy with it, and it works, then we can
> look at switching over.
>
>
>>
>> Reed
>>
>>
>>
>> On 09/14/2013 03:46 PM, Chandler Carruth wrote:
>>
>>>  I just wanted to give everyone a head up. I'm starting work on
the pass
>>> manager based on numerous list discussions and some IRC
discussions.
>>>
>>> The first steps will be marking the existing code as
"legacy" and
>>> clearing a path to build new facilities here. From there I'll
start
>>> building the new facilities without enabling them.
>>>
>>> Some explicit legacy support goals:
>>>
>>> 1) I'm going to build a bridge so that an existing Pass can be
inserted
>>> into the new pass manager with some adaptors and everything will
just
>>> work. This may require touching the code that sets up the pass
manager,
>>> but not the code that defines a pass. This will work even once the
new
>>> pass manager bits are enabled if at all possible.
>>>
>>> 2) If you have code that includes the current PassManager headers,
>>> nothing should break right away, but when the new manager
infrastructure
>>> is enabled, I'll likely remove the old PassManager headers,
breaking
>>> this code. My goal is to only break code that directly interacts
with
>>> the management layer.
>>>
>>> 3) I'm going to play namespace games so that we don't end
up with
>>> PassManagerV2 and other silly names. The legacy headers will paper
over
>>> this to keep legacy code compiling without change.
>>>
>>> -Chandler
>>>
>>>
>>>  _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130914/c3287c04/attachment.html>

On Sat, Sep 14, 2013 at 7:05 PM, Chandler Carruth <chandlerc at
google.com>wrote:
> On Sat, Sep 14, 2013 at 3:57 PM, Reed Kotler <rkotler at mips.com>
wrote:
>
>> Hi Chandler,
>>
>> What changes are you planning to make?
>>
>> Are you going to submit a proposal and RFC?
>>
>
> There have been several RFCs...
>
> What's your specific question?
>
> I'm planning to essentially try to build a new pass management layer
that
> doesn't suffer from the problems the existing one does. I could
describe
> every interface I plan in prose and email it out, but I'm not sure
that's
> really the most effective way to do it. My plan has been to work on
> implementing the new system in-tree, and let folks code review it and pick
> it apart as usual. When folks are happy with it, and it works, then we can
> look at switching over.
>
>
I think it would be nice just to centralize the results of all discussions
thus far in a google doc or whatever.

I don't recall ever seeing in one place a listing of the primary issues
that the rewrite is meant to address. I've definitely seen various
discussions here and there from time to time, but nothing that a person
could look at and get a big picture view of what's happening and why.

-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130915/d978e11c/attachment.html>

On Sun, Sep 15, 2013 at 8:08 PM, Sean Silva <silvas at purdue.edu> wrote:
>
>
>
> On Sat, Sep 14, 2013 at 7:05 PM, Chandler Carruth <chandlerc at
google.com>wrote:
>
>> On Sat, Sep 14, 2013 at 3:57 PM, Reed Kotler <rkotler at
mips.com> wrote:
>>
>>> Hi Chandler,
>>>
>>> What changes are you planning to make?
>>>
>>> Are you going to submit a proposal and RFC?
>>>
>>
>> There have been several RFCs...
>>
>> What's your specific question?
>>
>> I'm planning to essentially try to build a new pass management
layer that
>> doesn't suffer from the problems the existing one does. I could
describe
>> every interface I plan in prose and email it out, but I'm not sure
that's
>> really the most effective way to do it. My plan has been to work on
>> implementing the new system in-tree, and let folks code review it and
pick
>> it apart as usual. When folks are happy with it, and it works, then we
can
>> look at switching over.
>>
>>
>
> I think it would be nice just to centralize the results of all discussions
> thus far in a google doc or whatever.
>
> I don't recall ever seeing in one place a listing of the primary issues
> that the rewrite is meant to address. I've definitely seen various
> discussions here and there from time to time, but nothing that a person
> could look at and get a big picture view of what's happening and why.
>
> -- Sean Silva
>
Do'h, just saw you mention downthread of the "Pass Manager Redux"
you
posted like a year ago ("redux" was apparently the word that was
missing
from all my mail searches). (It's been a year, can you blame me for not
remembering? ;) )

-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130915/f0a36990/attachment.html>

>>Hi Chandler,
>>>
>>>What changes are you planning to make?
>>>
>>>Are you going to submit a proposal and RFC?
>>>
>>
>>
>>There have been several RFCs...
>>
>>
>>What's your specific question?
>>
>>
>>I'm planning to essentially try to build a new pass management layer
that doesn't suffer from the problems the existing one does. I could
describe every interface I plan in prose and email it out, but I'm not sure
that's really the most effective way to do it. My plan has been to work on
implementing the new system in-tree, and let folks code review it and pick it
apart as usual. When folks are happy with it, and it works, then we can look at
switching over.
>> 
>
> I think it would be nice just to centralize the results of all discussions
thus far in a google doc or whatever.

Why not make a blog post? That is where we have put similar things before (e.g.
type system changes, MC)


- Jan