[LLVMdev] Heads up: Pass Manager changes will be starting shortly

[Chandler Carruth]

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>