On Wed, Jun 8, 2016 at 2:50 PM, Jan Hubicka <hubi...@ucw.cz> wrote:
>> On Wed, Jun 8, 2016 at 2:35 PM, Jan Hubicka <hubi...@ucw.cz> wrote:
>> >> On 06/08/2016 12:21 PM, Andreas Schwab wrote:
>> >> > Jan Hubicka <hubi...@ucw.cz> writes:
>> >> >
>> >> >> Bootstrapped/regtested x86_64-linux, will commit it later today.
>> >> >
>> >> > FAIL: gcc.dg/tree-ssa/slsr-8.c scan-tree-dump-times optimized " w?\\\\*
>> >> > " 7
>> >> >
>> >> > Andreas.
>> >> >
>> >>
>> >> Hi.
>> >>
>> >> It's caused by a different probabilities for BB 2:
>> >>
>> >> @@ -11,11 +11,11 @@
>> >> ;; 3 succs { 4 }
>> >> ;; 4 succs { 1 }
>> >> Predictions for bb 2
>> >> - DS theory heuristics: 78.4%
>> >> - first match heuristics (ignored): 85.0%
>> >> - combined heuristics: 78.4%
>> >> - pointer (on trees) heuristics: 85.0%
>> >> - early return (on trees) heuristics: 39.0%
>> >> + DS theory heuristics: 66.5%
>> >> + first match heuristics (ignored): 70.0%
>> >> + combined heuristics: 66.5%
>> >> + pointer (on trees) heuristics: 70.0%
>> >> + early return (on trees) heuristics: 46.0%
>> >
>> > I see this is because sinking is done when PARAM_SINK_FREQUENCY_THRESHOLD
>> > is met and that is 75% which seems quite ambitious for guessed profiles
>> > that tends to be flat. (also the code should use counts where available).
>> > For some optimizers we have two thresholds - one for guessed profile and
>> > one
>> > for FDO. Perhaps it would make sense to benchmark how decreasing this
>> > threshold
>> > affect performance & code size.
>> >
>> > What are the downsides of sinking? Increased register pressure?
>>
>> Possibly. But that depends on the whole stmt chain that is eventually be
>> sunken
>> and this heuristic is for single stmts - which makes it somewhat fishy. I'd
>
> Yep, the usual problem ;)
>
>> simply benchmark removing it ... Eventually it tries to avoid sinking to
>> post-dominated blocks this way (those should have the same frequency), not
>> sure.
>
> Ruling out post-dominators in addition to checking profile would definitly be
> useful safety check and you probably don't want to sink into loops (ont sure
> if that can happen). I will take a look.
That is already taken care of with the loop depth check.
I think "sinking" into post-dominated regions should be done by a hypothetical
GIMPLE scheduling pass. I'm not sure the sinking pass will even consider such
locations (you'd have to double check).
Richard.
> Honza
