[cfe-dev] Controlling instantiation of templates from PCH

Lubos Lunak via cfe-dev cfe-dev at lists.llvm.org
Mon May 27 06:29:04 PDT 2019


 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.

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.

-- 
 Lubos Lunak



More information about the cfe-dev mailing list