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

[Chandler Carruth]

On Mon, May 7, 2012 at 10:48 AM, Argyrios Kyrtzidis <kyrtzidis at apple.com>wrote:

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

Yes, specifically the case is pushing and poping state to track a stack
structure during the traversal.


>
>
> 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 tend to agree I think... it is quite frustrating to loose the natural
recursive structuring, but, alas....
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120507/8f5a5bbc/attachment.html>