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
