[cfe-dev] zapcc compiler

[David Blaikie]

On Mon, May 25, 2015 at 12:37 PM, Yaron Keren <yaron.keren at gmail.com> wrote:

> zapcc maintains as much as possible from previous compilations: AST, IR,
> MC and DebugInfo.  I'm not sure that module support goes that far.
>

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.

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.

- David


> 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,
>

Actually it was available in '98, so far as I know.


> programmers unfamiliar with the technique or because it's cleaner and
> easier to #include the template header and let the compiler handle the
> housekeeping.
>

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)).


> 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
>>
>>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150526/f92a1b4f/attachment.html>