llunak added a comment.

In D69778#1928111 <https://reviews.llvm.org/D69778#1928111>, @dblaikie wrote:

> In D69778#1927761 <https://reviews.llvm.org/D69778#1927761>, @llunak wrote:
>
> > It comes from 08c5a7b8fda1b97df9d027d1ac096f93edeb6c2f . AFAICT 
> > -fmodules-codegen is a superset of -building-pch-with-obj, the important 
> > difference is that -building-pch-with-obj decides which code will be shared 
> > while building TUs, while -fmodules-codegen decides while building the PCH.
>
>
> I'm not sure I follow - how would that be possible? building the object from 
> the PCH is done independently of any usage, so it can't depend on the way the 
> PCH is used by any TU that includes it, I think?


If a TU uses a PCH, it'll result in some code emitted in every TU that uses the 
same PCH (e.g. template instantiations from the PCH). And 
-building-pch-with-obj detects these and discards them in all TUs except the 
PCH's object file. That means that the code shared in the PCH's object file is 
only code that would be duplicated in all TUs using the PCH. This is 
fundamentally different from -fmodules-codegen, which decides what will be 
emitted and shared already when creating the PCH, which has the consequence 
that it selects also a lot of code that will be eventually unused, which causes 
problems like the -Wl,--gc-sections part or not being necessarily worth it 
(IIRC even your -fmodules-codegen commit says so). So while -fmodules-codegen 
should be generally superior, -building-pch-with-obj is trivial to use. That's 
my understanding of both the approaches (and I spent quite a lot of time 
looking at both when working on D69778 <https://reviews.llvm.org/D69778> and 
D69585 <https://reviews.llvm.org/D69585>).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69778/new/

https://reviews.llvm.org/D69778



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to