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

[Chandler Carruth]

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.

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

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

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/20120504/d6eca36a/attachment.html>