<div class="gmail_quote">On Mon, May 7, 2012 at 10:48 AM, Argyrios Kyrtzidis <span dir="ltr"><<a href="mailto:kyrtzidis@apple.com" target="_blank">kyrtzidis@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div class="im"><div>On May 4, 2012, at 9:51 PM, Chandler Carruth wrote:</div><br><blockquote type="cite"><div class="gmail_quote">On Fri, May 4, 2012 at 9:35 PM, Ted Kremenek <span dir="ltr"><<a href="mailto:kremenek@apple.com" target="_blank">kremenek@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Author: kremenek<br>
Date: Fri May  4 23:35:20 2012<br>
New Revision: 156229<br>
<br>
URL: <a href="http://llvm.org/viewvc/llvm-project?rev=156229&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=156229&view=rev</a><br>
Log:<br>
Revert r156141 (making RecursiveASTVisitor data recursive).  It is causing clang to blow up in memory usage on -O2 when compiling itself,<br>
which is leading to swapping in some cases when it didn't before.  We need to see if we can make this change<br>
without leading to a massive compile-time bloat.<br></blockquote><div><br></div><div>Hey Ted, Argyrios;</div><div><br></div><div>I wanted to let you know that r156141 also broke a bunch of RecursiveASTVisitor users we have due to the change of call sequencing when operating in a data-recursive manner.</div>
</div></blockquote><div><br></div></div><div>Was this due to the clients depending on something like this ? :</div><div><br></div><div>bool Traverse*Stmt(..) {</div><div>  doSomethingBeforeTraversing();</div><div>  base::Traverse*Stmt();</div>
<div>  doSomethingAfterTraversing();</div><div>}</div><div><br></div><div>and getting broken since base::Traverse*Stmt() only queued the children ?</div></div></div></blockquote><div><br></div><div>Yes, specifically the case is pushing and poping state to track a stack structure during the traversal.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="im"><div><br></div><blockquote type="cite"><div class="gmail_quote">

<div><br></div><div>Given the persistent problems we're having with this class, I'd like to sit down, and take a *really* close look at exactly what we can and can't do here to address the very wide and varied use cases while retaining efficiency and avoiding blowing out the stack on deeply nested ASTs. Two fundamental ideas:</div>

<div><br></div><div>1) Re-shape the interface in a way that supports the various users we have through a completely data-recursive algorithm (no mixed operation), clearly without the memory overhead you're seeing, or</div>
</div></blockquote><div><br></div></div><div>I'm in favor of this.</div><div class="im"><br><blockquote type="cite"><div class="gmail_quote">
<div><br></div><div>2) Find a way to cause the common override patterns actually form tail-recursion in the crucial recursive steps when built with Clang/LLVM.</div></div></blockquote><div><br></div></div><div>This seems "fragile" because a client can override any method as it wants and it'd very easy to break the optimization, which we won't know until a crash happens.</div>
</div></div></blockquote><div><br></div><div>I tend to agree I think... it is quite frustrating to loose the natural recursive structuring, but, alas.... </div></div>