[Bug tree-optimization/106293] [13/14 Regression] 456.hmmer at -Ofast -march=native regressed by 19% on zen2 and zen3 in July 2022

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106293

--- Comment #17 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 27 Jul 2023, hubicka at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106293
> 
> --- Comment #15 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
>    if (bb_loop_depth (best_bb) == bb_loop_depth (early_bb)
>        /* If result of comparsion is unknown, prefer EARLY_BB.
>          Thus use !(...>=..) rather than (...<...)  */
> -      && !(best_bb->count * 100 >= early_bb->count * threshold))
> +      && !(best_bb->count * 100 > early_bb->count * threshold))
>      return best_bb;
> 
> Comparing loop depths seems ceartainly odd.  
> If we want to test best_bb and early_bb to be in same loop, we want to test
> loop_father.  What is a benefit of testing across loop nests?

This heuristic wants to catch

  <sink stmt>
  if (foo) abort ();
  <place to sink>

and avoid sinking "too far" across a path with "similar enough"
execution count (I think the original motivation was to fix some
spilling / register pressure issue).  The loop depth test
should be !(bb_loop_depth (best_bb) < bb_loop_depth (early_bb))
so we shouldn't limit sinking to a more outer nest.  As we rule
out > before this becomes ==.

It looks tempting to sink to the earliest place with the same
execution count rather than the latest but the above doesn't
really achive that (it doesn't look "upwards" but simply fails).
With a guessed profile it's also going to be hard.

And it in no way implements register pressure / spilling sensitivity
(see also Ajits attempts at producing a patch that avoids sinking
across a call).  All these are ultimatively doomed unless we at least
consider a group of stmts together.