<div dir="ltr"><div>Sorry for the delayed response.<br><br>I'm getting a bit confused by the layers of this thread, so I'll see if I can sum up my understanding & see if that's any use.<br><br>Currently there's a difference between PCH and Clang Header Modules semantics with regard to pending instantiations<br>In PCH, pending instantiations are all performed at any use of the PCH.<br>In modules pending instantiations are done at the end of building the header module (so they're performed once).<br>This difference is the cause of the original compile time cost you were investigating (somewhat independent of the duplicate code in object files)<br><br>So, step 1) perhaps we can just remove the PCH mode ^ here, and do the header module thing (perform pending instantiations at the end of building the PCH) for PCH as well.<br>If you want to do this ^ work, I think a patch would be welcome (I don't know much about where the distinction is between PCH and modules that causes this difference in how pending instantiations are handled - I might be able to find the code a little easier than you, but perhaps you can have a look around & see if you can find it - or Richard might be able to tell you/us)<br><br><br>Separate from that, there's some desire to be able to build an object file from a PCH to remove duplicate template instantiations in object files. (reducing compile time, reducing object size, maybe reducing link time).<br>To do this - it sounds like there's already a flag (-building-pch-with-obj) for building PCHs that will have a separate object file. I've no idea what this flag does today - does it already do what you want in terms of moving template instantiations and inline functions into that object? Or does it do something else (what else?)? If it doesn't do what you want already, and you want to extend it to do what you want - yes, I'd recommend piggy-backing on the exsiting Clang Header Modules modular code generation features for this.<br><br>& yes, potentially the pending instantiations could be moved over from the PCH-or-header-module generation step, to the PCH-or-header-module->Object step. (to benefit both PCH and header modules)<br><br>- Dave</div><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 31, 2019 at 2:36 PM Lubos Lunak <<a href="mailto:l.lunak@centrum.cz" target="_blank">l.lunak@centrum.cz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Friday 31 of May 2019, David Blaikie wrote:<br>
> On Thu, May 30, 2019 at 6:04 AM Lubos Lunak <<a href="mailto:l.lunak@centrum.cz" target="_blank">l.lunak@centrum.cz</a>> wrote:<br>
> > >  Two questions come to mind here:<br>
> > > - is it reasonably ready for use?<br>
> > > - how much work would it be to use it?<br>
> > ><br>
> > >  I tried Clang modules after they were mentioned in the first reply,<br>
> > > and I got the impression that they need preparation for every header<br>
> > > file used by the project, even external ones. Unless that can be<br>
> > > automated, I don't <br>
> > > quite see that happening for something the size and complexity of<br>
> > > LibreOffice (we don't manually create our headers-to-become-PCHs<br>
> > > either). And an unofficial tongue-in-cheek motton of LibreOffice is<br>
> > > "proudly breaking your toolchain since 1985", so unless modules are<br>
> > > reasonably usable, we'll run into all the bugs there and nobody will<br>
> > > want to use it.<br>
> > ><br>
> > >  If doing this is good technically, long-term, fine, do it. But I'd<br>
> > > like to<br>
> > > have something that works this summer, and my rather simple patch can<br>
> > > deliver that.<br>
> ><br>
> >  And so this part would be irrelevant in that case I hope?<br>
><br>
> Right. (I mean, a separate question is whether you'd want to use modules -<br>
> but yes, at the very least it does involve standardizing your headers on<br>
> "well behaved" sort of restraints (basically "you can include the header<br>
> anywhere, any time, and it always behaves the same way" - so not having<br>
> headers that depend on macros locally defined to different values in<br>
> different translation units, etc) - but yeah, it's a lot more work than the<br>
> PCH situation)<br>
<br>
<br>
 We can try modules eventually, but as said above, I expect the switch to <br>
those would be possibly quite some work, and there's also the question how <br>
build tools like ccache and icecream would cope with modules, so unlikely <br>
now.<br>
<br>
><br>
> > > > * Moving the pending instantiation processing to the end of the PCH<br>
> > > > would make PCH generation a little slower, but given a project would<br>
> > > > only have one PCH that might not be a huge problem.<br>
> > ><br>
> > >  I think that would be very well worth it.<br>
> ><br>
> >  This should be the same either way.<br><br>
 Just to make it clear, this means "this should be worth it for either case of <br>
whether I understood correctly or not that we should use modules". However <br>
I'm later basically contradicting this by saying that if the build mode is <br>
switched to generate an object file to aacompany the PCH then this shouldn't <br>
be done.<br>
<br>
> Yeah, I think I'd misunderstood your proposal - I had assumed there was a<br>
> separation between PCH generation and the PCH->Object step (& in that<br>
> latter step, the pending instantiations would be done). Sounds like your<br>
> .h->PCH step also generates the object?<br>
<br>
<br>
 My current plan is still to have a separate PCH->object step, but the idea <br>
now is to use -building-pch-with-obj. So the build steps now should be:<br>
<br>
# generate PCH and mark it as having accompanying .o<br>
clang++ -c precompiled.hxx -o precompiled.pch -Xclang -building-pch-with-obj<br>
# generate that .o<br>
clang++ -c empty.cxx -include-pch <br>
precompiled.pch -Xclang -building-pch-with-obj<br>
# compile the rest<br>
clang++ -c whatever.cxx -include-pch precompiled.pch<br>
<br>
 So the first step will mark the PCH, the second step will generate all the <br>
shared code, and the remaining steps will see the PCH as marked and will skip <br>
generating things again. I like this separation better than /Yu merging the <br>
first two steps into one, here each step generates just one output and <br>
compilations depending on the PCH can already run alongside generating the <br>
PCH's object. And keeping instantiating PCH templates the way it is now <br>
instead of moving it to the end of PCH creation would mean that work is done <br>
only in the second step, so the PCH generation wouldn't get slower. <br>
<br>
 And this could be easily later extended to e.g. non-template inline functions <br>
that get out-of-line copies in debug mode:<br>
- Are we using a marked PCH and -building-pch-with-obj is set? => generate <br>
shared copies<br>
- Are we using a marked PCH but -building-pch-with-obj is not set? => skip <br>
generation<br>
- The PCH is not marked as having an object? => work normally<br>
<br>
 I don't know how this relates to modules, but for PCHs I expect this should <br>
work fine.<br>
<br>
> But I still suspect whatever that implements isn't quite modules-codegen,<br>
> but I could be wrong.<br>
<br>
<br>
 I still don't quite get how modules relate to my patch, so I can't really <br>
comment on this.<br>
<br>
-- <br>
 Lubos Lunak<br>
</blockquote></div></div>
</div>