This is the mail archive of the gcc-patches@gcc.gnu.org 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: [wide-int] small cleanup in wide-int.*


Kenneth Zadeck <zadeck@naturalbridge.com> writes:
>>>>>    #define WIDE_INT_MAX_ELTS \
>>>>> -  ((4 * MAX_BITSIZE_MODE_ANY_INT + HOST_BITS_PER_WIDE_INT - 1) \
>>>>> -   / HOST_BITS_PER_WIDE_INT)
>>>>> +  (((MAX_BITSIZE_MODE_ANY_INT + HOST_BITS_PER_WIDE_INT - 1)	\
>>>>> +    / HOST_BITS_PER_WIDE_INT) + 1)
>>>> I think this should be:
>>>>
>>>>     (MAX_BITSIZE_MODE_ANY_INT / HOST_BITS_PER_WIDE_INT + 1)
>>>>
>>>> We only need an extra HWI if MAX_BITSIZE_MODE_ANY_INT is an exact multiple
>>>> of HOST_BITS_PER_WIDE_INT.
>>> we will do this later when some other issues that Eric B raised are settled.
>> I think you're talking about defining MAX_BITSIZE_MODE_ANY_INT as
>> MAX_SIZE_MODE_ANY_INT * BITS_PER_UNIT, but that's orthogonal to the
>> change above.  IMO it doesn't make sense to both round up the division
>> and also add 1 to the result.  So I think we should make this change
>> regardless of whatever follows.
>>
>> Looks good to me otherwise, thanks.
>>
>> Richard
>>
> so this one works the way you want.    While it is true the the problems 
> are disjoint, the solution will likely evolving change the same lines of 
> source in two different ways.

Well, if we're changing the definition of WIDE_INT_MAX_ELTS now (and we are)
I think we should change it to something that makes sense.  All we want is
1 extra bit.  We don't need to round up the size and then add a whole
HWI on top.  Doing that will potentially pessimise targets that don't
need anything beyond SImode.

It's not like I can approve the patch anyway though, so I'll leave it there.

Thanks,
Richard


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