tobiasvk added a comment.

In https://reviews.llvm.org/D34156#779270, @pcc wrote:

> Have you considered writing the regular LTO summaries unconditionally if 
> `-flto` was specified? That was how I imagined that the interface would look.


Absolutely, if people are OK with that. I would have enabled it by default in 
our tree anyway. Let me know if you prefer this (and other people if you have 
objections).

> Also, how were you planning to expose the reference graph to the linker? I 
> gather from your message that you are teaching your linker to read the module 
> summary index directly from bitcode files.

Yep, pretty much. I have a layer between the linker and LLVM that implements a 
`getRefsBySymbol` API which lets the linker iterate the reference graph. We've 
had this out of tree for some time, it's just that your recent patch made it 
straightforward to implement upstream.

> I wonder whether it would be worth trying to avoid needing to read summaries 
> multiple times. The approach that I had in mind was to somehow teach the 
> linker to add regular object files to the combined summary index by creating 
> a "global value summary" for each section, with a reference for each 
> relocation. (This would be similar to how we add regular LTO inputs to the 
> combined summary in https://reviews.llvm.org/D33922.) Then LTO would run as 
> usual. Any regular object sections would then naturally participate in the 
> summary-based dead stripping that LTO already does.

It could be done but I'm skeptical about this from a cost/benefit perspective. 
We'd only save one additional read of the summaries, which is pretty cheap 
anyway. The GC logic in the linker is non-trivial and doesn't map particularly 
well to the combined summary (e.g. we'd have to deal with the liveness of 
groups of symbols rather than individual ones when symbols share an input 
section).

Thanks,
Tobias


https://reviews.llvm.org/D34156



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

Reply via email to