> 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.
Honza
