Re: [patch] Update profile in loop versioning and unrolling

[Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>]

Hello,

> > > 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?
> > 
> > we used to, but my patch removes this assert.  There are two places
> > where my patch needs to upscale the frequencies (corresponding to the
> > checks you pointer out):
> > 
> > 1) In loop unrolling, we upscale the frequencies of the blocks after
> >    the removed loop exits.
> > 2) At the moment, the estimated profile makes it appear that loops
> >    iterate 10 times.  When we unroll such loop e.g. 16 times (which often
> >    happens in prefetching), there would be no way how to make the
> >    profile consistent; to avoid this problem, we upscale the frequencies
> >    of the unrolled loop to make it appear to roll at least 5 times (the
> >    constant 5 being just an arbitrary choice).
> 
> 
> I see, both those changes should not generally make us to upscale over
> original maximal frequency of the loop itself, right?

in the second case, yes (with some care, as you describe below).  If the
profile is inconsistent, this does not have to be true in the first
case, though.

Zdenek

> The second one can be dangerous if the loop was predicted to iterate for
> whatever reason just 2 times and we upscaled unrolled version to 5,
> multiplying the maximal frequency by over a factor of 2.
> Can the code be changed to watch the maximal frequency within a loop or
> possibly just upscale the unrolled loop to iterate same number of times
> as the original loop?
> 
> Honza