Re: [wide-int] Update main comment

[Richard Sandiford <rdsandiford at googlemail dot com>]

Kenneth Zadeck <zadeck@naturalbridge.com> writes:
> On 10/30/2013 07:01 AM, Richard Sandiford wrote:
>> Kenneth Zadeck <zadeck@naturalbridge.com> writes:
>>> On 10/29/2013 06:37 PM, Richard Sandiford wrote:
>>>> This patch tries to update the main wide_int comment to reflect the current
>>>> implementation.
>>>>
>>>> - bitsizetype is TImode on x86_64 and others, so I don't think it's
>>>>     necessarily true that all offset_ints are signed.  (widest_int are
>>>>     though.)
>>> i am wondering if this is too conservative an interpretation.    I
>>> believe that they are ti mode because that is the next thing after di
>>> mode and so they wanted to accommodate the 3 extra bits. Certainly there
>>> is no x86 that is able to address more than 64 bits.
>> Right, but my point is that it's a different case from widest_int.
>> It'd be just as valid to do bitsizetype arithmetic using wide_int
>> rather than offset_int, and those wide_ints would have precision 128,
>> just like the offset_ints.  And I wouldn't really say that those wide_ints
>> were fundamentally signed in any way.  Although the tree layer might "know"
>> that X upper bits of the bitsizetype are always signs, the tree-wide_int
>> interface treats them in the same way as any other 128-bit type.
>>
>> Maybe I'm just being pedantic, but I think offset_int would only be like
>> widest_int if bitsizetype had precision 67 or whatever.  Then we could
>> say that both offset_int and widest_int must be wider than any inputs,
>> meaning that there's at least one leading sign bit.
> this was of course what mike and i wanted, but we could not really 
> figure out how to pull it off.
> in particular, we could not find any existing reliable marker in the 
> targets to say what the width of the widest pointer on any 
> implementation.   We actually used the number 68 rather than 67 because 
> we assumed 64 for the widest pointer on any existing platform, 3 bits 
> for the bits and 1 bit for the sign.

Ah yeah, 68 would be better for signed types.

Is the patch OK while we still have 128-bit bitsizetypes though?
I agree the current comment would be right if we ever did switch
to sub-128 bitsizes.

Thanks,
Richard