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

[Jan Hubicka <jh at suse dot cz>]

> Hello,
> 
> > > > 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.
> > 
> > Hmm, I guess we can make scale_bb_frequencies first downscale the
> > fraction representation to it's own multiplications don't overflow and
> > additionally forcingly reudce all frequencies over FREQ_MAX to be
> > FREQ_MAX so we stay in the safe range (I think also the verification is
> > good idea, but if you won't do that, I will just drop it into TODO).
> 
> there are some problems with strongly requiring all frequencies to be <=
> FREQ_MAX (e.g. if you expanded memcpy in the innermost
> loop, you could not set the frequencies in the new loop to anything
> sane).  I somewhat suspect that with inconsistent profile, we may be
> sometimes generating frequencies over FREQ_MAX even now; I guess I do
> not have time at the moment to enable the verification and deal with
> the bug reports.

Yes, I am aware that find_sub_basic_blcoks and likely few other passes
needs fixing to enforce this invariant, but it seems only sane way to
prevent overflows in overall (if we let the frequencies to increase over
FREQ_MAX in some passes, it is just question of time until some testcase
appears where the increases cumulate and cause overflow).  I will write
the verifier sometime after New Year and see what needs to be fixed.

The patch is OK if you change scale_bb_frequencies_int to watch overflow
in multiplication and cut frequencies on FREQ_MAX and avoid the two
overflow checks eariler in code (unless you have some argument why this
should produce inferior results).

Thanks!
Honza
> 
> Zdenek