On Mon, Dec 9, 2013 at 3:49 PM, Kenneth Zadeck <zad...@naturalbridge.com> wrote:
> On 12/08/2013 05:35 AM, Richard Biener wrote:
>>
>> Richard Sandiford <rdsandif...@googlemail.com> wrote:
>>>
>>> Kenneth Zadeck <zad...@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?

Otherwise ok.

Thanks,
Richard.

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

Reply via email to