This is the mail archive of the gcc-patches@gcc.gnu.org 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


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.
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


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