This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


> > 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?
> 
> 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?

Also perhaps I would love to see the scale function to still sanity
check for monotone decrease but be a just wrapper of one that is allowed
to upscale.  That way we can use the upscaling version only in the cases
we upscale for good reasons, like the two you mentioned while still
having sanity checkes elsewhere.
These things area easy to get wrong...

Honza
> 
> Honza


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]