Kenneth Zadeck <[email protected]> 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
always use TREE_INT_CST_EXT_NUNITS.)
Thanks,
Richard
