<div dir="ltr">On Sat, Sep 14, 2013 at 3:57 PM, Reed Kotler <span dir="ltr"><<a href="mailto:rkotler@mips.com" target="_blank" class="cremed">rkotler@mips.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Chandler,<br>
<br>
What changes are you planning to make?<br>
<br>
Are you going to submit a proposal and RFC?<br></blockquote><div><br></div><div>There have been several RFCs...</div><div><br></div><div>What's your specific question?</div><div><br></div><div>I'm planning to essentially try to build a new pass management layer that doesn't suffer from the problems the existing one does. I could describe every interface I plan in prose and email it out, but I'm not sure that's really the most effective way to do it. My plan has been to work on implementing the new system in-tree, and let folks code review it and pick it apart as usual. When folks are happy with it, and it works, then we can look at switching over.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Reed<div><div class="h5"><br>
<br>
<br>
On 09/14/2013 03:46 PM, Chandler Carruth wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
I just wanted to give everyone a head up. I'm starting work on the pass<br>
manager based on numerous list discussions and some IRC discussions.<br>
<br>
The first steps will be marking the existing code as "legacy" and<br>
clearing a path to build new facilities here. From there I'll start<br>
building the new facilities without enabling them.<br>
<br>
Some explicit legacy support goals:<br>
<br>
1) I'm going to build a bridge so that an existing Pass can be inserted<br>
into the new pass manager with some adaptors and everything will just<br>
work. This may require touching the code that sets up the pass manager,<br>
but not the code that defines a pass. This will work even once the new<br>
pass manager bits are enabled if at all possible.<br>
<br>
2) If you have code that includes the current PassManager headers,<br>
nothing should break right away, but when the new manager infrastructure<br>
is enabled, I'll likely remove the old PassManager headers, breaking<br>
this code. My goal is to only break code that directly interacts with<br>
the management layer.<br>
<br>
3) I'm going to play namespace games so that we don't end up with<br>
PassManagerV2 and other silly names. The legacy headers will paper over<br>
this to keep legacy code compiling without change.<br>
<br>
-Chandler<br>
<br>
<br></div></div>
______________________________<u></u>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank" class="cremed">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank" class="cremed">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank" class="cremed">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvmdev</a><br>
<br>
</blockquote>
<br>
<br>
</blockquote></div><br></div></div>