<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 25, 2015 at 12:37 PM, Yaron Keren <span dir="ltr"><<a href="mailto:yaron.keren@gmail.com" target="_blank">yaron.keren@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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.</div></div></blockquote><div><br>ASTs are preserved in modules, that's all they're for (parsing time tends to dominate, at least in our world/experiments/data as I understand it, so that's the first thing to fix). Duplicate IR/MC/DebugInfo is still present though it'd be the next thing to solve - we're talking about deduplicating some of the debug info and Adrian Prantl is working on that at the moment - putting debug info for types into the module files themselves and referencing it directly as a split DWARF file. <br><br>Duplicate IR/MC comes from comdat/linkonce_odr functions - and at some point it'd be nice to put those in a module too, if there's a clear single ownership (oh, you have an inline function in your modular header - OK, we'll IRGen it, make an available_externally copy of it in the module to be linked into any users of the module, and a standard external definition will be codegen'd down to object code and put in the module to be passed to the linker). This wouldn't solve the problems with templates that have no 'home' to put their definition.<br><br>- David<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="rtl"><div dir="ltr"> 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, </div></div></blockquote><div><br>Actually it was available in '98, so far as I know.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="rtl"><div dir="ltr">programmers unfamiliar with the technique or because it's cleaner and easier to #include the template header and let the compiler handle the housekeeping.</div></div></blockquote><div><br>Yeah, the usual problem is that it's a maintenance burden to couple template definitions to the types they're instantiated with (& often impossible - because the template is in a library that doesn't know about the instantiated types at all (like std::vector - it can't know all the types in the world that it might be instantiated with)).<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="rtl"><div dir="ltr"> Whatever reason, zapcc handles this automatically.</div><span class=""><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></span></div>
<br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div></div>