http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674
--- Comment #19 from Jan Hubicka <hubicka at ucw dot cz> 2012-12-21 16:15:34
UTC ---
> As another data point, in our internal benchmarks I had tried a few
> values and 99.9% gave the best performance. Just going down to 99.0%
> reduced the inlining too much, even compared to the old static cutoff
> count, missing some key inlines and reducing performance.
this really should not happen too much. I still think something along the
following lines
is desirable. Does it helps setting more resonable threshold?
Honza
Index: predict.c
===================================================================
*** predict.c (revision 194655)
--- predict.c (working copy)
*************** maybe_hot_count_p (struct function *fun,
*** 145,151 ****
{
ws = find_working_set (PARAM_VALUE (HOT_BB_COUNT_WS_PERMILLE));
gcc_assert (ws);
! min_count = ws->min_counter;
}
return (count >= min_count);
}
--- 145,156 ----
{
ws = find_working_set (PARAM_VALUE (HOT_BB_COUNT_WS_PERMILLE));
gcc_assert (ws);
!
! /* We want all counters above ws->min_counter * profile_info->runs
! to be safely identified as hot regions. This may be spoiled
! by optimizations such as unrolling that reduce counts of the
! body, thus divide by 32. */
! min_count = ws->min_counter / 32;
}
return (count >= min_count);
}
