[cfe-commits] r99002 - in /cfe/trunk: include/clang/Frontend/PCHBitCodes.h include/clang/Frontend/PCHReader.h include/clang/Frontend/PCHWriter.h include/clang/Lex/PreprocessingRecord.h lib/Frontend/PCHReader.cpp lib/Frontend/PCHWriter.cpp lib/Lex/PreprocessingRecord.cpp test/Index/c-index-getCursor-test.m tools/CIndex/CIndex.cpp

[Douglas Gregor]

On Mar 19, 2010, at 2:51 PM, Douglas Gregor wrote:

> Author: dgregor
> Date: Fri Mar 19 16:51:54 2010
> New Revision: 99002
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=99002&view=rev
> Log:
> Implement serialization and lazy deserialization of the preprocessing
> record (which includes all macro instantiations and definitions). As
> with all lay deserialization, this introduces a new external source
> (here, an external preprocessing record source) that loads all of the
> preprocessed entities prior to iterating over the entities.
> 
> The preprocessing record is an optional part of the precompiled header
> that is disabled by default (enabled with
> -detailed-preprocessing-record). When the preprocessor given to the
> PCH writer has a preprocessing record, that record is written into the
> PCH file. When the PCH reader is given a PCH file that contains a
> preprocessing record, it will be lazily loaded (which, effectively,
> implicitly adds -detailed-preprocessing-record). This is the first
> case where we have sections of the precompiled header that are
> added/removed based on a compilation flag, which is
> unfortunate. However, this data consumes ~550k in the PCH file for
> Cocoa.h (out of ~9.9MB), and there is a non-trivial cost to gathering
> this detailed preprocessing information, so it's too expensive to turn
> on by default. In the future, we should investigate a better encoding
> of this information.

This has some performance issues with clang_getCursor(), which I'm investigating now. They only have an effect when using -detailed-preprocessing-record, so it's not worth reverting.

	- Doug