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

[Paweł Bylica]

Is there any example how to use the new pass manager (how to replace the
legacy one with the new one)?

On Fri, Feb 13, 2015 at 11:08 AM Chandler Carruth <chandlerc at gmail.com>
wrote:

> 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
>>>
>>>
>>
> _______________________________________________
> 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/20150428/5fbd67da/attachment.html>