Re: [wide-int] small cleanup in wide-int.*

[Richard Sandiford <rdsandiford at googlemail dot com>]

Richard Biener <richard.guenther@gmail.com> writes:
> On Thu, Nov 28, 2013 at 6:11 PM, Kenneth Zadeck
> <zadeck@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).

Thanks,
Richard