Re: [PATCH] New fdo summary-based icache sensitive unrolling (issue6351086)

[Teresa Johnson <tejohnson at google dot com>]

On Tue, Dec 11, 2012 at 10:12 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> On 2012.12.11 at 09:13 -0800, Teresa Johnson wrote:
>> > Ping.
>> > Teresa
>> >
>> > On Mon, Nov 19, 2012 at 4:58 PM, Teresa Johnson <tejohnson@google.com> wrote:
>> > > This patch was proposed awhile back, and the new working set program
>> > > summary was split out and committed separately. I would like to
>> > > see if the loop unroller part of the patch can now go in. For the
>> > > previous versions of the patch and related discussion, see:
>> > >
>> > > http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00437.html
>> > > and
>> > > http://gcc.gnu.org/ml/gcc-patches/2012-07/msg01373.html
>> > >
>> > > Use the new working set information in the FDO program summary for
>> > > codesize based unroll and peel decisions, to prevent those
>> > > optimizations from increasing code size too much when the
>> > > program may be sensitive to icache effects.
>> > >
>> > > As part of this, cache additional loop analysis results in the niter_desc
>> > > auxiliary information hanging off the loop structure to reduce
>> > > redundant analyses during unrolling.
>> > >
>> > > Bootstrapped and tested on x86_64-unknown-linux-gnu. Ok for trunk?
>>
>> I guess this is the missing piece that would fix the Firefox lto/pgo
>> code-size issue:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375#c144
>
> It won't help in this case - the problem is that too much of code is identified as hot,
> similar as for spec2k GCC benchmark.  Teresa - do you have any ideas what to do here
> short of re-adding the BB ratio parameter and combining both heuristics for 4.8?

Right, I doubt this patch would help. I looked through the bugzilla
log and it is most likely inlining increases. What was the size of the
gcc lto/pgo binary before the change to use the histogram? Was it
close to the gcc 4.7 lto/pgo size? In that case that is a very large
increase, ~25%.

Markus, could you attach to the bug one of the gcda files so that I
can see the program summary and figure out how far off the old hot bb
threshold is from the new histogram-based one? Also, it would be good
to see the -fdump-ipa-inline dumps before and after the regression (if
necessary, the before one could be from 4_7).

I'll update the bug with the same, so that we can track the discussion there.

Thanks,
Teresa

>
> Honza
>>
>> --
>> Markus



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