> 2018-11-28 Pat Haugen <pthau...@us.ibm.com> > > PR rtl-optimization/68212 > * cfgloopmanip.c (duplicate_loop_to_header_edge): Adjust scale factor. > > testsuite/ChangeLog: > 2018-11-28 Pat Haugen <pthau...@us.ibm.com> > > PR rtl-optimization/68212 > * gcc.dg/pr68212.c: New test. > > > > Index: gcc/cfgloopmanip.c > =================================================================== > --- gcc/cfgloopmanip.c (revision 266522) > +++ gcc/cfgloopmanip.c (working copy) > @@ -1242,16 +1242,25 @@ duplicate_loop_to_header_edge (struct lo > profile_probability prob_pass_main = bitmap_bit_p (wont_exit, 0) > ? prob_pass_wont_exit > : prob_pass_thru; > - profile_probability p = prob_pass_main; > - profile_count scale_main_den = count_in; > - for (i = 0; i < ndupl; i++) > + > + /* If not using real profile data then don't scale the loop by ndupl. > + This can lead to the loop no longer looking hot wrt surrounding > + code. */ > + if (profile_status_for_fn (cfun) == PROFILE_GUESSED) > + scale_main = profile_probability::likely ();
profile_status_for_fn is not very informative when you inline FDO to non-FDO code (via LTO or when profile was lost for COMDAT). You want to test count_in.reliable_p () which will return true for FDO profiles but not for guessed profiles and Auto-FDO. If we know number of iterations at compile time (which is relatively frequent for unrolled loops) we actually put in correct profile with a cap given by --param max-predicted-iterations (which may make sense to get higher). In that case we probably do not want to drop this information from profile. Can't we get to scale only if the profile looks wrong - count_in gets unrealistically small compared to cfgloop expected number of iterations info says (or when it is absent)? Honza
