[cfe-dev] Designing a clang incremental compiler server

[Reid Kleckner]

On Wed, Jun 16, 2010 at 6:04 PM, Chris Lattner <clattner at apple.com> wrote:
> On Jun 16, 2010, at 2:47 PM, Douglas Gregor wrote:
>>> Pre-compiled headers already do this, but they generally only work for
>>> projects that use the '#include "world.h"' header style.  My goal is
>>> to either improve the existing pre-compiled header support so that
>>> this restriction can be lifted, or do something else entirely.
>>
>> However, I don't think the restriction requiring that the PCH include come first in the translation unit (the prefix header approach) can be lifted in any practical system that doesn't require the system headers to change.
>
> I completely agree.

Having gotten now several opinions from people who know C++ better
than I, I have realized that this is not a tractable problem for C++.
It seems much more promising for something like C.

>> 1) Live with this limitation, building the compilation server ... and of course there are other opportunities for sharing (mmap'd file buffers, tokenized files, etc.)
>
> If you're looking to make a real impact in a realistic timeframe, I think this approach is the right answer.  I think you can actually get a pretty significant win out of just doing something simple like:
>
> 1. Make a shared multi-threaded compiler server process that individual 'clang' invocations talk to.
> 2. The compiler server caches headers as pre-lexed token streams, similar to a persistent PTH, but without requiring any setup.
> 3. For projects that already do use PCH, the PCH file can be cached by the compiler server making them benefit from PCH even more.
>
> I think that just getting this level of sharing would be a pretty big win (20%?) for C++ projects building on a multicore machine, and the win will go up as Clang++ gets faster in other ways.  For example, someday we'll do the obvious "lazy creation of implicit member" optimization that G++ does (speeding up Sema), eventually ELF systems will support the integrated assembler, fastisel is going to get faster, etc.  As these other things get faster, more percentage of time is spent in the preprocessor.
>
> After this first level is implemented, then we talk about doing incremental/modular parsing, and other interesting things.  For example, if clang ASTs are immutable once created (we're close to that, but not fully there) then you could imagine a "checkpointing" mechanism where .cpp files which share a common prefix can share declarations and avoid reparsing the common prefix.  Another idea is to use information in the compiler server to know what templates are instantiated in one .o file to avoid re-instantiating/codegen'ing redundant stuff in other .o file.  This is also useful for vtables that have no key method etc.
>
> These sorts of optimizations are "big wins" but really need something like a compiler server to get a more holistic view of the build.  To answer your higher level question: YES this would be a great project!  Please start small and build obviously useful stuff (in mainline) like the basic compiler server.  Once the obviously useful stuff is there, it will be more clear which of the crazy ideas is the biggest win (because we can measure to make educated guesses) and most possible to implementable.

Great, I'm glad to hear there are other reasons to pursue this.

Right now I'm trying to improve -ftime-report to do some simple
profiling that breaks down time spent into broad categories, like
lexing, PP, parse, sema, irgen, iropt, and codegen.  That way I can
actually know if any of this will be profitable enough.  Expect a
patch soon.

Reid