Chandler Carruth
2015-Jan-28 20:56 UTC
[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>
Philip Reames
2015-Jan-28 23:04 UTC
[LLVMdev] Would like to force one minor, mechanical change on out-of-tree users of the old pass manager
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. > > -ChandlerFine by me. Philip
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-02 18:39 UTC
[LLVMdev] Would like to force one minor, mechanical change on out-of-tree users of the old pass manager
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>
Maybe Matching Threads
- [LLVMdev] Would like to force one minor, mechanical change on out-of-tree users of the old pass manager
- [LLVMdev] please advise on PassManager
- [LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers
- [LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers
- [LLVMdev] Using an alias analysis pass