[cfe-commits] r156229 - /cfe/trunk/include/clang/AST/RecursiveASTVisitor.h

Argyrios Kyrtzidis kyrtzidis at apple.com
Mon May 7 10:48:35 PDT 2012


On May 4, 2012, at 9:51 PM, Chandler Carruth wrote:

> On Fri, May 4, 2012 at 9:35 PM, Ted Kremenek <kremenek at apple.com> wrote:
> Author: kremenek
> Date: Fri May  4 23:35:20 2012
> New Revision: 156229
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=156229&view=rev
> Log:
> Revert r156141 (making RecursiveASTVisitor data recursive).  It is causing clang to blow up in memory usage on -O2 when compiling itself,
> which is leading to swapping in some cases when it didn't before.  We need to see if we can make this change
> without leading to a massive compile-time bloat.
> 
> Hey Ted, Argyrios;
> 
> 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.

Was this due to the clients depending on something like this ? :

bool Traverse*Stmt(..) {
  doSomethingBeforeTraversing();
  base::Traverse*Stmt();
  doSomethingAfterTraversing();
}

and getting broken since base::Traverse*Stmt() only queued the children ?

> 
> 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:
> 
> 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

I'm in favor of this.

> 
> 2) Find a way to cause the common override patterns actually form tail-recursion in the crucial recursive steps when built with Clang/LLVM.

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.

> 
> I haven't looked into the feasibility or challenges of either of these really, just speculating at the two strategies. Can you share some of the investigation you've done? Do you have test cases, or synthetic stress-testing we can use to reproduce the deep nesting structures that I can use when looking at this? Any ideas for alternative solutions?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120507/491ad41b/attachment.html>


More information about the cfe-commits mailing list