[cfe-dev] Controlling instantiation of templates from PCH

[Lubos Lunak via cfe-dev]

On Thursday 30 of May 2019, Lubos Lunak via cfe-dev wrote:
> On Wednesday 29 of May 2019, David Blaikie wrote:
> > 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


 Oh, wait, "semantics". I originally understood this as a kind of "do not use 
PCHs, use modules", but I might have misunderstood. If this actually means 
that PCHs should internally handle templates etc. the same way modules do, 
but to the outside world they would still keep looking like normal PCHs, then 
yeah, sure, as long as it works.


> > 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.


 And so this part would be irrelevant in that case I hope?

> > * 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.


 This should be the same either way.

> > * 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?


 This part supported my understanding as "use modules instead of PCHs", so I'm 
not sure which interpretation you meant, but that's not the correct one, then 
I think these flags are not really needed, at least for PCHs. The step of 
creating an object file accompanying the PCH can be easily achieved 
using "clang++ -c empty.cpp -include-pch 
whatever.h.pch -Xclang -building-pch-with-obj", internally the 
BuildingPCHWithObjectFile flag can be used for controlling special handling 
as such the need to force emitting the shared code, and doing it as another 
separate step would help with build parallelization. So, in fact, this way 
there would be no need to move the processing of pending instantiations to 
the end of PCH if BuildingPCHWithObjectFile is set.

-- 
 Lubos Lunak