[Bug gcov-profile/55674] [4.8 Regression] >20% size increase of lto/pgo binaries since r193747

[tejohnson at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674

--- Comment #18 from Teresa Johnson <tejohnson at google dot com> 2012-12-19 16:44:21 UTC ---
On Tue, Dec 18, 2012 at 9:25 AM, hubicka at ucw dot cz
<gcc-bugzilla@gcc.gnu.org> wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674
>
> --- Comment #17 from Jan Hubicka <hubicka at ucw dot cz> 2012-12-18 17:25:37 UTC ---
>> I did some measurements with tramp3d and in this case
>> the default (999) gives the best performance:
>>
>> par. size    time
>> --------------------
>> 999  955859  3.71752
>> 990  933390  3.73969
>> 980  904718  3.84547
>> ...    "        "
>> 750  904718  3.84769
>> 740  837654  7.67177
>> 600  836024  8.80879
>
> Yep, tramp3d is unforutnately quite special case: we measure the number of
> instructions prior
> late optimization, while in tramp3d over 90% of code disappear as a result of
> inlining and further
> simplification, so we get GIGO problem...
>
> I am not sure how to handle these things in any resonable way....
>
> I will test couple of values on spec2k this week and lets see how things scale
> elsewhere.

As another data point, in our internal benchmarks I had tried a few
values and 99.9% gave the best performance. Just going down to 99.0%
reduced the inlining too much, even compared to the old static cutoff
count, missing some key inlines and reducing performance.

Thanks,
Teresa

>
> Honza
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.



--
Teresa Johnson | Software Engineer | tejohnson@google.com | 408-460-2413