pcc added a comment. In https://reviews.llvm.org/D34156#779661, @tobiasvk wrote:
> 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). I'd be fine with it. We may want to make it conditional on the target (e.g. the summary wouldn't be much use on Darwin targets right now), but let's see what others think. >> 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). That's a fair point, and now that I think about it it does seem better for GC to be entirely driven by the linker, as you have done. Longer term we may consider replacing summary-based dead stripping entirely with linker-driven dead stripping. https://reviews.llvm.org/D34156 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits