<div dir="rtl"><div dir="ltr">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.</div><div dir="ltr"><br></div><div dir="ltr">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.</div><div dir="ltr"><br></div><div class="gmail_extra"><br><div class="gmail_quote"><div dir="ltr">2015-05-24 19:41 GMT+03:00 Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span>:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On May 23, 2015, at 12:25 PM, Yaron Keren <<a href="mailto:yaron.keren@gmail.com" target="_blank">yaron.keren@gmail.com</a>> wrote:<br>
> 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.<br>
<br>
</span>This sounds like a very interesting approach, but also (as you say) very complex :-)<br>
<br>
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.<br>
<span><font color="#888888"><br>
-Chris<br>
<br>
</font></span></blockquote></div><br></div></div>