[cfe-dev] Controlling instantiation of templates from PCH

[David Blaikie via cfe-dev]

On Mon, May 27, 2019 at 6:29 AM Lubos Lunak <l.lunak at centrum.cz> wrote:

>
>  Let me merge answers to various parts into one mail:
>
> On Sunday 26 of May 2019, Richard Smith wrote:
> > This seems like a nice idea, and has a lot in common with our existing
> > "modular codegen" mode, which does largely the same thing but for PCMs
> > rather than PCHs. I'd hope we could share a lot of the implementation
> > between the two features.
>
>  The core of my patch is basically an if statement in
> Sema::InstantiateFunctionDefinition() that decides whether to bail out and
> avoid doing something that'd eventually get thrown away anyway, so
> speaking
> of sharing implementation is probably bit of a stretch. Unless you mean
> that
> the problem should be rather handled by changing how PCHs internally work,
> which I have no idea about.
>
> On Monday 27 of May 2019, David Blaikie via cfe-dev wrote:
> > Though do you know if/how any of this could account for /more/ time spent
> > with pending instantiations with a PCH than without? (assuming the same
> > headers are included - and that's perhaps where the assumption is
> > incorrect/flawed, perhaps in Lubos's case the PCH is being added in
> > addition to the headers used in the non-PCH build, rather than instead
> of)
>
>  That assumption is indeed incorrect. E.g. for libsclo we have
> precompiled_sc.hxx, which contains everything that makes sense to be in
> PCH
> for the library. And it is used as -include-pch precompiled_sc.hxx.pch,
> but
> only if PCH is enabled. That's the reasonable way to use it, except for
> MSVC
> PCHs are not considered worth it and so are not enabled by default, and it
> doesn't make sense to include more than necessary in the non-PCH case. So
> the
> increase in time spent in PerformPendingInstantiations() is (AFAICT)
> caused
> solely by the PCH bringing in more stuff. Presumably if we used
> precompiled_sc.hxx unconditionally we'd always have this cost.
>

Ah, OK. Good to understand.


>
> On Sunday 26 of May 2019, David Blaikie wrote:
> > Lubos: Could you provide a small standalone example of this increase in
> > pending instantiations so it's a bit easier for me to understand the kind
> > of code & what's happening?
>
> $ cat a.cpp
> // empty source file
> $ cat a.h
> #include <vector>
> struct F
>     {
>     std::vector< char > c;
>     int size() { return c.size(); }
>     };
> $ ... make Clang print info in Sema::InstantiateFunctionDefinition() ...
> $ clang++ -Wall -c a.cpp
> [nothing]
> $ clang++ -Wall -c a.cpp -include a.h
> INST:std::_Hash_impl::hash
> INST:std::_Hash_impl::hash
> INST:std::vector<char, std::allocator<char> >::size
>
>  You get the same with -include-pch a.h.pch . Also, I'm on Linux, so this
> is
> libstdc++, but I assume it'll be similar with libc++.
>
>  The important thing to note is that the resulting object file is the same
> in
> both cases, the instantiated functions eventually get thrown away. But
> Clang
> has to spend time processing that, and as you can see in the -ftime-trace
> graphs that can get very costly.
>

OK.

So I'm not sure I understand this comment:

"And, if you look carefully, 4 seconds more to generate code, most of it
for those templates. And after the compiler spends all this time on
templates in all the source files, it gets all passed to the linker, which
will shrug and then throw most of it away (and that will too take a load of
time, if you still happen to use the BFD linker instead of gold/lld
<https://lists.freedesktop.org/archives/libreoffice/2018-July/080484.html>
 with -gsplit-dwarf -Wl,--gdb-index
<https://lists.freedesktop.org/archives/libreoffice/2018-June/080437.html>).
What a marvel."

What extra code generation occurred with the PCH? Any change in generated
code with a PCH would surprise me.

- Dave


>
> --
>  Lubos Lunak
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190527/72262180/attachment.html>