[cfe-dev] zapcc compiler

[Yaron Keren]

zapcc maintains as much as possible from previous compilations: AST, IR, MC
and DebugInfo.  I'm not sure that module support goes that far. This indeed
would be easier to implement if we know that the C++ code is properly
modularized.

One example, if a compile unit instantiates StringMap<bool> and the next
compile unit also requires it, StringMap<bool> should not to be
reinstantiated, codegenned and optimized. This could mostly achieved using
extern + explicit template instantiations however this approach is quite
rare. Maybe because extern template wasn't supported before C++11,
programmers unfamiliar with the technique or because it's cleaner and
easier to #include the template header and let the compiler handle the
housekeeping. Whatever reason, zapcc handles this automatically.


2015-05-24 19:41 GMT+03:00 Chris Lattner <clattner at apple.com>:

> On May 23, 2015, at 12:25 PM, Yaron Keren <yaron.keren at gmail.com> wrote:
> > zapcc makes distinction between two classes of source files, the
> "system" ones of which all compilation state is kept in memory and the
> "user" ones whose compilation state is removed once compiled. The
> programmer can select which are the "user" files by wildcards set in a
> configuration files. The default of user is .c .cpp .cxx .CC files but it
> could easily be all files in /home/user/yaron or whatever. It is expected
> that the system files are non-changing (such a change will not be
> recognized anyhow until server restart) while the user files are the ones
> to be modified. As an example, you could have
> llvm/lib/MC/MachObjectWriter.cpp as the "user" file so every other file
> compilation result would be kept in memory.
>
> This sounds like a very interesting approach, but also (as you say) very
> complex :-)
>
> Have you looked at the modules work in clang?  It seems that building on
> that infrastructure could help simplify things.  In principle you could
> load “all the modules” and then treat any specific translation unit as a
> filter over the available decls.  This is also, uhm, nontrivial, but
> building on properly modular headers could simplify things a lot.
>
> -Chris
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150525/6b7c903f/attachment.html>