Re: Reorgnanization of profile count maintenance code, part 1

[Segher Boessenkool <segher@kernel.crashing.org>]

On Wed, Jun 07, 2017 at 11:11:08PM +0200, Jan Hubicka wrote:
> > On Tue, Jun 06, 2017 at 10:25:29PM +0200, Jan Hubicka wrote:
> > > > On Thu, Jun 01, 2017 at 01:35:56PM +0200, Jan Hubicka wrote:
> > > > > +      /* FIXME: shrink wrapping violates this sanity check.  */
> > > > > +      gcc_checking_assert ((num >= 0
> > > > > +			    && (num <= REG_BR_PROB_BASE
> > > > > +			        || den <= REG_BR_PROB_BASE)
> > > > > +			    && den > 0) || 1);
> > > > > +      ret.m_val = RDIV (m_val * num, den);
> > > > > +      return ret;
> > > > 
> > > > Sorry if I missed this...  But where/how does it violate this?
> > > 
> > > It sums multiple probabilties together and overflows the limit.
> > 
> > Ah.  Yes, the scale it uses (num/den in shrink-wrap.c:924) isn't a
> > probability: it's a just a fraction, but also <= 1.  The calculation cannot
> > overflow, not while there are at most 4G incoming edges to a BB.
> 
> Problem is that when you multiply count by it, the buffer is considerably
> smaller, because count itself can be quite large number...

Oh duh, I stupidly looked at the frequency thing, not the count thing.

> It is not too bad - I added the sanity check mostly to see if there
> is a safe cap on num so I do not need to worry about overflows at all.

For count we can round a bit without causing problems, I think?  No
such luxury with frequency, but, that's not the issue here :-)


Segher