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

[Chandler Carruth]

FYI, this has landed in r229094.

On Mon, Feb 2, 2015 at 10:39 AM, Chandler Carruth <chandlerc at gmail.com>
wrote:

> 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/20150213/40a26a19/attachment.html>