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

["hubicka at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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?

Profile report here claims:
dump id |static mismat|dynamic mismatch                                     |   
        |in count     |in count                  |time                      |   
lsplit  |      5    +5|   8151850567  +8151850567| 531506481006       +57.9%| 
ldist   |      9    +4|  15345493501  +7193642934| 606848841056       +14.2%| 
ifcvt   |     10    +1|  15487514871   +142021370| 689469797790       +13.6%| 
vect    |     35   +25|  17558425961  +2070911090| 517375405715       -25.0%| 
cunroll |     42    +7|  16898736178   -659689783| 452445796198        -4.9%|  
loopdone|     33    -9|   2678017188 -14220718990| 330969127663             |   
tracer  |     34    +1|   2678018710        +1522| 330613415364        +0.0%|  
fre     |     33    -1|   2676980249     -1038461| 330465677073        -0.0%|  
expand  |     28    -5|   2497468467   -179511782|--------------------------|

so looks like loop splitting, distribution and vectorizer does disturb profile
signficantly. 
(Ifcft does so by design and the damage is undone later.)
Not sure if that is the real problem though.