<div dir="ltr"><div>Given the lack of concern (and thanks Philip for the explicit ACK), planning to make this change this week.</div><div><br></div>FWIW, I also chatted with David off line to explain some of the background here.<div><br></div><div>-Chandler</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 29, 2015 at 11:21 AM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Wed, Jan 28, 2015 at 12:56 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Greetings folks.<div><br></div><div>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.</div><div><br></div><div>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.</div></div></blockquote></span><div><br>What was the change in particular that broke modules?<br><br>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?<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><div dir="ltr"><div>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.<br></div><div><br></div><div>However, the changes would only be required for Pass*Manager* and related classes. Neither Pass, FunctionPass, or PassManagerBuilder would change.</div><div><br></div><div>Any objections to this? While it clearly has cost and would not be my preferred approach, the benefits seem to outweigh the costs here.</div><span><font color="#888888"><div><br></div><div>-Chandler</div></font></span></div>
<br></span><span class="">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></span></blockquote></div><br></div></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div>