This is the mail archive of the 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: endless loop in compute_inverse bootstrapping on alpha

On Fri, Aug 23, 2002 at 10:10:29PM +0200, Michael Ritzert wrote:
> Am Freitag, 23. August 2002 19:24 schrieb Zack Weinberg:
> > Yes, OBJECT_SIZE(32) should definitely be nonzero.
> >
> > Simply changing the local 'size' and 'inv' variables in
> > compute_inverse to size_t won't work in general; you're still storing
> > back to a 32-bit field in the inverse_table, which means the
> > multiplier will get truncated and won't work properly.  You luck out
> > because all the page orders of size >= 2^32 are powers of two, which
> > means inverse_table[order].mult will come out 1 for all of them (all
> > the work is done by inverse_table[order].shift, which can only go as
> > high as 64).
> Doesn't your patch contradict your statement here?  On the one hand
> you always set .shift to 0, which ist different from what the
> algorithm would compute without the patch.  On the other hand you
> say that .shift is the one important value.
> Ok.  As I understand it, one doesn't have to care about the values for big 
> orders as they will never be used anyway, right?

Yes and no to both.

It happens that the offset within the page of an object on a big-order
page will always be zero.  That means the actual values stored in
inverse_table[] for that page are not terribly important, as
(0*mult)>>shift == 0 for all values of 'mult' and 'shift'.

It also happens that the value computed for 'mult', for all current
big-order pages, will be 1, because all the current big-order pages
have an object size that's a power of two.  Therefore, under your
patch, the inverse_table parameters will be computed correctly, and
should we ever get two objects in a big-order page (this is
impossible) the division would be carried out correctly.  If we ever
got big-order pages with object sizes that weren't powers of two, the
multiplier wouldn't be 1, so first version of your patch would break.
The second version, which enlarges the multiplier field, would work
correctly; however, I'd prefer not to double the size of the
inverse_table[] if it can be avoided.

I prefer my patch because it makes an explicit assumption -- that
big-order pages can contain only one object -- verifies it, and then
uses values which are safe and predictable.  And because it doesn't
require the inverse_table to be bigger.


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