[cfe-dev] Controlling instantiation of templates from PCH

[David Blaikie via cfe-dev]

On Thu, May 30, 2019 at 6:04 AM Lubos Lunak <l.lunak at centrum.cz> wrote:

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

Right - that's what I was suggesting. Sorry for the confusion.


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

Right. (I mean, a separate question is whether you'd want to use modules -
but yes, at the very least it does involve standardizing your headers on
"well behaved" sort of restraints (basically "you can include the header
anywhere, any time, and it always behaves the same way" - so not having
headers that depend on macros locally defined to different values in
different translation units, etc) - but yeah, it's a lot more work than the
PCH situation)


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

Yeah, I think I'd misunderstood your proposal - I had assumed there was a
separation between PCH generation and the PCH->Object step (& in that
latter step, the pending instantiations would be done). Sounds like your
.h->PCH step also generates the object?


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

I didn't realize there was already a building-pch-with-obj option - I see
now that there is. Sorry for the confusion there.

But I still suspect whatever that implements isn't quite modules-codegen,
but I could be wrong.


>
> --
>  Lubos Lunak
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190531/3edbf99d/attachment.html>