[PATCH] D29701: ThinLTOBitcodeWriter: Write available_externally copies of VCP eligible functions to merged module.

[Peter Collingbourne via Phabricator via llvm-commits]

pcc added a comment.

In https://reviews.llvm.org/D29701#675809, @pcc wrote:

> In https://reviews.llvm.org/D29701#674285, @mehdi_amini wrote:
>
> > In https://reviews.llvm.org/D29701#670366, @pcc wrote:
> >
> > > Note: I patched in https://github.com/pcc/llvm-project/commit/5a5904d6721f895eafdd2fc476872b98806c36e6 to measure perf impact. Total wall time spent in addRegularLTO when linking chrome was 8.2743s, as compared to about 6 seconds before (see https://reviews.llvm.org/D27324).
> >
> >
> > So >30% overhead on addRegularLTO, but what is the overhead for `runRegularLTO`?
>
>
> Just did a fresh set of runs on chrome with https://github.com/pcc/llvm-project/commits/lto-timers patched in, and took median of 5 for each measurement:
>
>                  before after
>   addRegularLTO 8.0407s 9.7432s (+21%)
>   runRegularLTO 9.6064s 10.4748s (+9%)
>
>
> Note that we haven't done everything we can -- a couple more things I can think of are to exclude functions that take non-integer arguments (other than "this"), and to set optnone on functions in the merged module. Taking a look at chrome's merged module, there are 6727 available_externally functions, of which 1340 take a pointer argument other than "this".


Another data point for chrome is that this change causes us to merge 53487 struct type definitions, most of which are likely unnecessary (I think they are either associated with "this", which we make sure is unused, or one of the other pointer arguments, which means we don't need the function). So something else we could do that would be a little more tricky is to try to drop the type information for "this". (Of course, this would happen for free if we had typeless pointers.)


https://reviews.llvm.org/D29701