[Bug tree-optimization/90911] [10 Regression] 456.hmmer regression with r272239

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2019-06-25
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
So looking at perf the reason seems obvious:

Samples: 717K of event 'cycles:pu', Event count (approx.): 586330968682         
Overhead  Command          Shared Object                  Symbol              
◆
  60.74%  hmmer_base.amd6  hmmer_base.amd64-m64-gcc42-nn  [.] P7Viterbi       
▒
  31.35%  hmmer_base.amd6  hmmer_base.amd64-m64-gcc42-nn  [.] P7Viterbi.cold  
▒
   2.32%  hmmer_base.amd6  hmmer_base.amd64-m64-gcc42-nn  [.] FChoose         
▒
   2.02%  hmmer_base.amd6  hmmer_base.amd64-m64-gcc42-nn  [.] sre_random       

and caused by

      /* ???  if-conversion uses profile_probability::always () but
         prob below is profile_probability::likely ().  */

thus we keep the profile from if-conversion which uses always () compared
to previously versioning the loop with the vectorized path being only
likely ().  The inconsistent profile from if-conversion persists and seems
to confuse us later:

  /* At this point we invalidate porfile confistency until IFN_LOOP_VECTORIZED
     is re-merged in the vectorizer.  */
  new_loop = loop_version (loop, cond, &cond_bb,
                           profile_probability::always (),
                           profile_probability::always (),
                           profile_probability::always (),
                           profile_probability::always (), true);

Just updating the edge probability of the guard seems to avoid creating
the bogus hot/cold partitioning and should not affect further copying
from the scalar loop from prologue/epilogue peeling.