[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