This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [wide-int] small cleanup in wide-int.*
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>, Kenneth Zadeck <zadeck at naturalbridge dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>, Mike Stump <mikestump at comcast dot net>, Richard Sandiford <rdsandiford at googlemail dot com>
- Date: Fri, 29 Nov 2013 12:41:25 +0100
- Subject: Re: [wide-int] small cleanup in wide-int.*
- Authentication-results: sourceware.org; auth=none
- References: <52977927 dot 5010008 at naturalbridge dot com> <CAFiYyc0+GZC6yGQjoOo66srn9-SaiDCJFf0TsVMLdFP_==qTow at mail dot gmail dot com> <8738mftpnk dot fsf at talisman dot default>
On Fri, Nov 29, 2013 at 12:26 PM, Richard Sandiford
<rdsandiford@googlemail.com> wrote:
> 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).
Yeah, we probably need the +1 for that.
Richard.
> Thanks,
> Richard