[PATCH] D34156: [LTO] Add -femit-summary-index flag to emit summary for regular LTO

[Tobias Edler von Koch via Phabricator via cfe-commits]

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