This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug gcov-profile/55674] [4.8 Regression] >20% size increase of lto/pgo binaries since r193747
- From: "tejohnson at google dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 11 Jan 2013 18:18:48 +0000
- Subject: [Bug gcov-profile/55674] [4.8 Regression] >20% size increase of lto/pgo binaries since r193747
- Auto-submitted: auto-generated
- References: <bug-55674-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674
--- Comment #22 from Teresa Johnson <tejohnson at google dot com> 2013-01-11 18:18:48 UTC ---
Hi Honza,
I ran a number of experiments at different thresholds, and found that
performance starts dropping pretty quickly as the working set
threshold is dropped, even to 98.5% (2 working sets lower than the
99.9% threshold). This appears to be due to a reduction in key
inlines. If I use your divide by 32 heuristic, the performance is
recovered for most of the apps I looked at (with the 98.5% threshold),
but is still reduced for others.
When I looked at the ratio of the min counter values between the
98.28% bucket (selected when I use the 98.5% threshold) and the 99.9%
bucket, I can see that the apps that still degrade with 98.5% + your
divide by 32 heuristic are those with the largest ratio (100-300). For
the apps that no longer degrade from the 98.5% thresholds when
dividing by 32, the ratio is small and often less than 32 (so in
effect the resulting min counter is even smaller than with the current
99.9% threshold).
What threshold were you thinking of changing it to, based on your
experiments? For the google branches, based on the data I collected,
we plan to leave it at 99.9%.
Thanks,
Teresa
On Sat, Dec 22, 2012 at 3:20 PM, hubicka at ucw dot cz
<gcc-bugzilla@gcc.gnu.org> wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674
>
> --- Comment #21 from Jan Hubicka <hubicka at ucw dot cz> 2012-12-22 23:20:37 UTC ---
>> I'll give this patch a try and let you know how it affects the
>> performance I see. But unrolling shouldn't affect inlining, since all
>> unrolling is after inlining, right?
>
> Well, it is, but we do other transformations that affect profile prior inlining
> + we use hot/cold code all across compilation, not just to drive inlining.
>
> 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.