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).

Zdenek


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