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.*


Richard Biener <richard.guenther@gmail.com> writes:
> On Mon, Dec 9, 2013 at 3:49 PM, Kenneth Zadeck <zadeck@naturalbridge.com> wrote:
>> On 12/08/2013 05:35 AM, Richard Biener wrote:
>>>
>>> Richard Sandiford <rdsandiford@googlemail.com> wrote:
>>>>
>>>> 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.
>>>
>>> I agree.
>>>
>>> Richard.
>>
>> Done, ok to commit?
>
> +   early examination of the target's mode file.  The WIDE_INT_MAX_ELTS
> +   can accomodate at least 1 more bit so that unsigned numbers of that
> +   mode can be represented.  Note that it is still possible to create
> +   fixed_wide_ints that have precisions greater than
> +   MAX_BITSIZE_MODE_ANY_INT.  This can be useful when representing a
> +   double-width multiplication result, for example.  */
>  #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))
> +
>
> that doesn't reserve 1 more bit, it just rounds up.  For one more bit you
> need to add 1, so
>
>  #define WIDE_INT_MAX_ELTS \
> +  (((MAX_BITSIZE_MODE_ANY_INT + 1 + HOST_BITS_PER_WIDE_INT - 1)    \
> +    / HOST_BITS_PER_WIDE_INT))
>
> no?

Or just:

   (MAX_BITSIZE_MODE_ANY_INT / HOST_BITS_PER_WIDE_INT + 1)

as above.

Richard


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