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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130914/8840e6b5/attachment.html>

Hi Chandler,

What changes are you planning to make?

Are you going to submit a proposal and RFC?

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
>

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 Sep 14, 2013, at 3:46 PM, Chandler Carruth <chandlerc at google.com>
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.
Great!  Aside from mailing list discussions, do you have a whitepaper that
describes the end-result that you're shooting for?  It doesn't need to
be overly formal, but something along the lines of
http://nondot.org/sabre/LLVMNotes/ would be useful.
> 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.
Sounds great to me, incremental is good.  I think it's perfectly fine to do
something like:

class PassManagerV2 { … }

#ifdef NEW_STUFF
#define PassManager PassManagerV2
#else
class PassManager { … }
#endif

or something.  It's horribly gross, but as long as you're committed to
finishing the work, it can be useful for staging the change.

-Chris

Great. Is this (at least partially) motivated by PGO? Am I correct in assuming
you want to solving the "inliner can't use branch probability"
problem?

Evan

On Sep 14, 2013, at 3:46 PM, Chandler Carruth <chandlerc at google.com>
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