This is the mail archive of the
mailing list for the GCC project.
Re: [patch] Update profile in loop versioning and unrolling
> > > scale_bbs_frequencies_int does not like numerator to be greater than
> > > 65536, the magic constants on both places ensure that we do not pass it
> > > invalid inputs.
> > I see, it is even asserted there. Can't just scale_bbs_frequencies_int
> > care itself to scale down num/den to stay within range rather than
> > forcing users to add such interesting checks?
> I a bit fear allowing the frequencies to be scalled by (almost)
> arbitrary factors (e.g. if we scale frequencies in some area by 1000,
> they are likely to grow much over BB_FREQ_MAX); I think there need
> to be some similar checks to avoid making absurd decisions because
> of previous mistakes in profile updating.
You are right that we don't want to scale the frequences up too high, we
compute third power of them in many cases, so even grwoing a little
above the allowed 10000 is dangerous (actually 14000 already owerflows).
Perhaps this ought to be sanity checked in verify_flow_info.
I wonder where the loop updating logic should possibly requrest
increasing expected number of iterations in the loop? i.e. within
inliner, where I can correctly increase maximal frequency by inlining a
hot loop I care to recompute frequencies overall either from counts or
probabilities when this happens (at least on IPA branch, on mainline we
don't have profile at that time yet). I have however dificulties to
think of ofther places in compiler where we produce new hot stuff,
possibly with exception of string function expanders (where I had to
work around this issue too).
I would expect that the scale_bbs_frequencies_int should get large num
only when den is large too. Perhaps we can even sanity check that the
function is consistently decreasing the frequencies, or is that too much
to hope for?