[cfe-dev] Controlling instantiation of templates from PCH

[Hans Wennborg via cfe-dev]

On Wed, May 29, 2019 at 1:18 PM Lubos Lunak <l.lunak at centrum.cz> wrote:
>
> On Wednesday 29 of May 2019, Hans Wennborg wrote:
> > On Tue, May 28, 2019 at 9:38 PM Lubos Lunak via cfe-dev
> > >  /Yc /Yu could act that way without extra flags, but I think they don't.
> > > I've just skimmed over the sources, so I may be mistaken, but it seems to
> > > me the /Yc mode is not different there. Unless /Yc somehow already
> > > instantiates everything in the PCH and avoids such instantiations in TUs
> > > using the PCH, there is still going to be the cost of
> > > Sema::PerformPendingInstantiations() doing something that's not needed.
> > > Remember that this is actually about improving the build time, not
> > > necessarily the build result.
> ...
> > I think this is more in the vein of
> > http://llvm.org/viewvc/llvm-project?view=revision&revision=335466
> >
> > We could know that the definitions of the instantiated templates are
> > in the PCH .obj file, and could hopefully skip it in other users of
> > the PCH. And that's probably how MSVC does it.
>
>
>  That commit is based on the same idea as mine, but it's not exactly the same.
> The point is that ASTContext::DeclMustBeEmitted() comes only after
> Sema::InstantiateFunctionDefinition(). So your commit should result in
> smaller object files and save the work of generating code for instantiations
> from PCH in every TU, but I do not see anything that'd affect
> Sema::InstantiateFunctionDefinition(), which is where the main cost of build
> time is in my case. Moreover your patch always emits decls if they're
> referenced, so it passes on the possibility to skip emitting those that are
> already in the PCH's object file. I think your patch as it is in practice
> makes a difference only for (dll)export-ed decls and nothing else, am I
> getting that right?

Yes exactly. I'm not saying it's the same, only that's it's a similar
direction: emitting some things in the PCH .obj file only, saving some
work in the other translation units.

>  But seeing that commit it makes sense to me to use the same base mechanism
> for deciding if these optimizations can be done. Am I getting it right
> that -building-pch-with-obj is really just a flag that gets written to
> the .pch file?

Yes.

> Then I think I can map my intended use to that easily
> (use -building-pch-with-obj when creating the .pch just to add the flag, use
> building-pch-with-obj -include-pch for empty source to create the
> accompanying .o and then remaining files use the .pch normally).

Yup, that's what's happening behind the scenes with clang-cl's /Yc and /Yu.