[cfe-dev] [Patch] Make ParseAST() take ASTContext and TU params

[Ted Kremenek]

On Jan 27, 2009, at 3:51 PM, Alexei Svitkine wrote:

> Oops - it looks like there was a change to ParseAST() earlier that I
> wasn't up to date with. This one:
>
> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090126/011412.html
>
> That change involves propagating the FreeMemory param to the
> ASTContext constructor... which is problematic with my change which
> gets rid of that param entirely. I'm not sure how to handle this.

The "FreeMemory" argument to ASTContext is a little of a misnomer.   
It's more a selector of which Allocator that ASTContext uses to  
allocate ASTs (i.e., MallocAllocator or BumpPtrAllocator).  Calling  
~ASTContext() will *always* release memory.  Feel free to rename that  
parameter to something more appropriate.

Much of your patch is orthogonal to these changes.  Your patch is  
about creating a new interface for ParseAST that allows clients to  
hold on the TranslationUnit/ASTContext after ParseAST has completed.

> What is the purpose of -disable-free in the context of the
> command-line clang tool?

Our timings show that a significant amount of time is spent in clang  
freeing ASTs.

When invoking 'clang' for compilation from the command-line, freeing  
ASTs is a waste of time since the OS will automatically reclaim that  
memory.  Providing -disable-free from the command line allows us to  
experiment with the performance of just having the OS free memory  
versus freeing the memory directly.

Moreover, having it as a command-line option (rather than hard-coded)  
allows us to free memory ASTs manually for debugging (to make sure all  
the ownership issues are correct) but still have the --disable-free  
option for production releases.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20090127/a88c0e50/attachment.html>