[cfe-dev] Controlling instantiation of templates from PCH

[Lubos Lunak via cfe-dev]

On Wednesday 29 of May 2019, David Blaikie wrote:
> On Tue, May 28, 2019 at 2:31 AM Lubos Lunak <l.lunak at centrum.cz> wrote:
> > - To put it differently, you can also view
> > -fpch-template-instantiation=skip
> > as automatic extern template for whatever is used by the PCH,
> > and -fpch-template-instantiation=force as explicit instantiation for it,
> > where all the hassle of extern template is replaced by just putting all
> > the
> > template stuff in the PCH. (To be precise, it's not exactly like explicit
> > instantiation, because it involves only what is instantiated by the PCH,
> > but
> > if wanted that can be handled by actually explicitly instantiating in the
> > PCH, without having to bother with the extern template stuff).
>
> Ah, OK. Was this an indirect benefit of the feature/patch you created - or
> did you specifically code for that in addition to the moving the pending
> instantiations out to the separate PCH processing stage, rather than in
> every compilation that uses the PCH - or did it come out as a happy
> coincidence?


 I'm not sure what you're referring to exactly with 'this' and 'that'. My 
patch does not move pending instantiations anywhere, it just avoids them in 
all but one compilation using the PCH. So whatever template you instantiate 
in the PCH, all those compilations don't have to spend any time on it.


> In any case, talking to Richard Smith about all this, here's some things:
>
> * Clang header modules don't have the pending instantiation performance
> problem described here - because they handle the pending instantiations at
> the end of building the module, rather than in every consumer.
> * It's possible moving PCH to the modules semantics might be valid in
> general, or good enough to put behind a flag. (doing this in general would
> of course be easier, code-wise - fewer supported code paths, etc)

 Two questions come to mind here:
- is it reasonably ready for use?
- how much work would it be to use it?

 I tried Clang modules after they were mentioned in the first reply, and I got 
the impression that they need preparation for every header file used by the 
project, even external ones. Unless that can be automated, I don't quite see 
that happening for something the size and complexity of LibreOffice (we don't 
manually create our headers-to-become-PCHs either). And an unofficial 
tongue-in-cheek motton of LibreOffice is "proudly breaking your toolchain 
since 1985", so unless modules are reasonably usable, we'll run into all the 
bugs there and nobody will want to use it.

 If doing this is good technically, long-term, fine, do it. But I'd like to 
have something that works this summer, and my rather simple patch can deliver 
that.

> * Moving the pending instantiation processing to the end of the PCH would
> make PCH generation a little slower, but given a project would only have
> one PCH that might not be a huge problem.

 I think that would be very well worth it.

> * In addition to that, we could support -fmodules-codegen/debuginfo - which
> would implement the "building an object from the PCH" step you've described
> using existing infrastructure in Clang (& that would then include other
> non-template inline functions, so it'd be a bit broader)
> * Then we could potentially do something more like what you're proposing
> here - if modules-codegen is used, defer pending instantiations from the
> initial module/PCH creation step, to the module/PCH-to-object step, to
> speed up module/PCH generation & unblock the downstream compilations that
> use it

 That could work for me too. And I'd be probably willing to help, if my Clang 
skill would be up to that. How much time/work would this be?

-- 
 Lubos Lunak