On Fri, Nov 29, 2013 at 12:26 PM, Richard Sandiford <rdsandif...@googlemail.com> wrote: > Richard Biener <richard.guent...@gmail.com> writes: >> On Thu, Nov 28, 2013 at 6:11 PM, Kenneth Zadeck >> <zad...@naturalbridge.com> wrote: >>> This patch does three things in wide-int: >>> >>> 1) it cleans up some comments. >>> 2) removes a small amount of trash. >>> 3) it changes the max size of the wide int from being 4x of >>> MAX_BITSIZE_MODE_ANY_INT to 2x +1. This should improve large muls and divs >>> as well as perhaps help with some cache behavior. >> >> @@ -235,8 +233,8 @@ along with GCC; see the file COPYING3. >> range of a multiply. This code needs 2n + 2 bits. */ >> >> #define WIDE_INT_MAX_ELTS \ >> - ((4 * MAX_BITSIZE_MODE_ANY_INT + HOST_BITS_PER_WIDE_INT - 1) \ >> - / HOST_BITS_PER_WIDE_INT) >> + (((2 * MAX_BITSIZE_MODE_ANY_INT + HOST_BITS_PER_WIDE_INT - 1) \ >> + / HOST_BITS_PER_WIDE_INT) + 1) >> >> I always wondered why VRP (if that is the only reason we do 2*n+1) >> cannot simply use FIXED_WIDE_INT(MAX_BITSIZE_MODE_ANY_INT*2 + 1)? >> Other widest_int users should not suffer IMHO. widest_int should >> strictly cover all modes that the target can do any arithmetic on >> (thus not XImode or OImode on x86_64). > > Do you want it to be 128 bits or 128+1 (rounded up)? If we stick to 128 > bits, we'll still have the problem that we like to see tree constants as > "infinite precision" while the integer we use to represent them cannot > distinguish between maximum-width signed and unsigned constants. > E.g. ~(uint64_t)0 is different from -(int64_t)1 but ~(uint128_t)0 is the > same as -(int128_t)1. That's true for double_int too but you said a few > months back that you saw that as a bug. > > By being able to represent 129 bits we're able to get rid of that corner > case (and consequently things like TREE_INT_CST_LT_UNSIGNED).
Yeah, we probably need the +1 for that. Richard. > Thanks, > Richard
