[cfe-dev] Clang as a compiler-only tool

Rafael EspĂ­ndola rafael.espindola at gmail.com
Tue Nov 27 07:48:25 PST 2012

> My team looked into making the static analyzer a plug-in.  One obstacle we found was that enabling plug-ins increases the start of time of clang.  On the Mac at least, we use export maps to restrict the set of symbols that are exported from the clang executable.  Enabling the plug-ins means we must export far more symbols from the executable, which would have a direct impact on the start up time of clang.  I do not remember the the exact numbers, but this regression in start-up time would be unacceptable.
> One possible direction is to create a clang service.  There has been some discussion before of doing this.  A clang service could amortize the cost of starting up over many separate compilations, and possibly provide a better way to enable plug-ins anyway.

Yes, unfortunately the way plugins are currently implemented (given
them access to all of the clang binary) is very expensive. This is
even more noticeable when using LTO on ELF systems. If enabling
plugins (linking with -export-dynamic), LTO cannot internalize much.

Another possibility that might work is to build a shared library that
exports only the symbols that plugins can use (just lib/AST maybe?)
and have both clang and plugins link with it.

In any case, these are all long term solutions, so I think something
along the lines Roman is proposing is a a reasonable compromise for


More information about the cfe-dev mailing list