llvm dev - Jan 2015 - [LLVMdev] Would like to force one minor, mechanical change on out-of-tree users of the old pass manager

Greetings folks.

I had really wanted out-of-tree folks to be able to make only a single
change to their code due to the new pass manager; essentially, by the time
they had to touch the code at all I wanted them to be able to port
completely to the new pass manager.

However, Richard has raised the issue that this is nearly impossible to
make work with C++ modules, and we've lost the modules build bot that was
checking our self host in this mode because of this.

So, now that 3.6 is branched, I wondered if folks would be OK with me
switching code to explicitly refer to some of the legacy constructs with
the "legacy" namespace. I'm absolutely committed to the new pass
manager
being done prior to 3.7 (actually, a lot sooner). So this would require
(entirely mechanical) source changes to out-of-tree users who are tracking
trunk in the interim.

However, the changes would only be required for Pass*Manager* and related
classes. Neither Pass, FunctionPass, or PassManagerBuilder would change.

Any objections to this? While it clearly has cost and would not be my
preferred approach, the benefits seem to outweigh the costs here.

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

On 01/28/2015 12:56 PM, Chandler Carruth wrote:
> Greetings folks.
>
> I had really wanted out-of-tree folks to be able to make only a single 
> change to their code due to the new pass manager; essentially, by the 
> time they had to touch the code at all I wanted them to be able to 
> port completely to the new pass manager.
>
> However, Richard has raised the issue that this is nearly impossible 
> to make work with C++ modules, and we've lost the modules build bot 
> that was checking our self host in this mode because of this.
>
> So, now that 3.6 is branched, I wondered if folks would be OK with me 
> switching code to explicitly refer to some of the legacy constructs 
> with the "legacy" namespace. I'm absolutely committed to the
new pass
> manager being done prior to 3.7 (actually, a lot sooner). So this 
> would require (entirely mechanical) source changes to out-of-tree 
> users who are tracking trunk in the interim.
>
> However, the changes would only be required for Pass*Manager* and 
> related classes. Neither Pass, FunctionPass, or PassManagerBuilder 
> would change.
>
> Any objections to this? While it clearly has cost and would not be my 
> preferred approach, the benefits seem to outweigh the costs here.
>
> -Chandler
Fine by me.

Philip

On Wed, Jan 28, 2015 at 12:56 PM, Chandler Carruth <chandlerc at
gmail.com>
wrote:
> Greetings folks.
>
> I had really wanted out-of-tree folks to be able to make only a single
> change to their code due to the new pass manager; essentially, by the time
> they had to touch the code at all I wanted them to be able to port
> completely to the new pass manager.
>
> However, Richard has raised the issue that this is nearly impossible to
> make work with C++ modules, and we've lost the modules build bot that
was
> checking our self host in this mode because of this.
>
What was the change in particular that broke modules?

I'm not quite understanding the setup we've ended up with that causes
this
problem - why is it that the new pass manager doesn't use a temporary
name/namespace until it finishes, leaving the original in place?

> So, now that 3.6 is branched, I wondered if folks would be OK with me
> switching code to explicitly refer to some of the legacy constructs with
> the "legacy" namespace. I'm absolutely committed to the new
pass manager
> being done prior to 3.7 (actually, a lot sooner). So this would require
> (entirely mechanical) source changes to out-of-tree users who are tracking
> trunk in the interim.
>
> However, the changes would only be required for Pass*Manager* and related
> classes. Neither Pass, FunctionPass, or PassManagerBuilder would change.
>
> Any objections to this? While it clearly has cost and would not be my
> preferred approach, the benefits seem to outweigh the costs here.
>
> -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/20150129/8fb6be61/attachment.html>

Given the lack of concern (and thanks Philip for the explicit ACK),
planning to make this change this week.

FWIW, I also chatted with David off line to explain some of the background
here.

-Chandler

On Thu, Jan 29, 2015 at 11:21 AM, David Blaikie <dblaikie at gmail.com>
wrote:
>
>
> On Wed, Jan 28, 2015 at 12:56 PM, Chandler Carruth <chandlerc at
gmail.com>
> wrote:
>
>> Greetings folks.
>>
>> I had really wanted out-of-tree folks to be able to make only a single
>> change to their code due to the new pass manager; essentially, by the
time
>> they had to touch the code at all I wanted them to be able to port
>> completely to the new pass manager.
>>
>> However, Richard has raised the issue that this is nearly impossible to
>> make work with C++ modules, and we've lost the modules build bot
that was
>> checking our self host in this mode because of this.
>>
>
> What was the change in particular that broke modules?
>
> I'm not quite understanding the setup we've ended up with that
causes this
> problem - why is it that the new pass manager doesn't use a temporary
> name/namespace until it finishes, leaving the original in place?
>
>
>> So, now that 3.6 is branched, I wondered if folks would be OK with me
>> switching code to explicitly refer to some of the legacy constructs
with
>> the "legacy" namespace. I'm absolutely committed to the
new pass manager
>> being done prior to 3.7 (actually, a lot sooner). So this would require
>> (entirely mechanical) source changes to out-of-tree users who are
tracking
>> trunk in the interim.
>>
>> However, the changes would only be required for Pass*Manager* and
related
>> classes. Neither Pass, FunctionPass, or PassManagerBuilder would
change.
>>
>> Any objections to this? While it clearly has cost and would not be my
>> preferred approach, the benefits seem to outweigh the costs here.
>>
>> -Chandler
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>
> _______________________________________________
> 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/20150202/69560a32/attachment.html>