Kenneth Zadeck <zad...@naturalbridge.com> writes: > On 10/30/2013 07:01 AM, Richard Sandiford wrote: >> Kenneth Zadeck <zad...@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