David Blaikie
2015-Jan-29 19:21 UTC
[LLVMdev] Would like to force one minor, mechanical change on out-of-tree users of the old pass manager
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>
Chandler Carruth
2015-Feb-13 10:03 UTC
[LLVMdev] Would like to force one minor, mechanical change on out-of-tree users of the old pass manager
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>