This is the mail archive of the 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] Update main comment

Kenneth Zadeck <> 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 is related to the way that we have to assert:

template <int N>
inline wi::extended_tree <N>::extended_tree (const_tree t)
  : m_t (t)
  gcc_checking_assert (TYPE_PRECISION (TREE_TYPE (t)) <= N);

rather than:

template <int N>
inline wi::extended_tree <N>::extended_tree (const_tree t)
  : m_t (t)
  gcc_checking_assert (TYPE_PRECISION (TREE_TYPE (t)) < N);

(which would give slightly better offset_int code, because we could then


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