This is the mail archive of the
mailing list for the GCC project.
Re: [wide-int] int_traits <tree>
- From: Kenneth Zadeck <zadeck at naturalbridge dot com>
- To: Mike Stump <mikestump at comcast dot net>, Richard Biener <rguenther at suse dot de>, gcc-patches at gcc dot gnu dot org, rdsandiford at googlemail dot com
- Date: Sat, 19 Oct 2013 08:54:02 -0400
- Subject: Re: [wide-int] int_traits <tree>
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot LNX dot 2 dot 00 dot 1310161537220 dot 11149 at zhemvz dot fhfr dot qr> <525EB50F dot 2090003 at naturalbridge dot com> <87ppr56on1 dot fsf at talisman dot default> <525EFC33 dot 4010304 at naturalbridge dot com> <87hacg720z dot fsf at talisman dot default> <alpine dot LNX dot 2 dot 00 dot 1310171015000 dot 11149 at zhemvz dot fhfr dot qr> <30C4C2A0-38C8-4F3B-80B2-7AEFFB99AD0D at comcast dot net> <alpine dot LNX dot 2 dot 00 dot 1310181037170 dot 11149 at zhemvz dot fhfr dot qr> <52613396 dot 3030605 at naturalbridge dot com> <DBA11B41-3B27-4AAF-BEA4-E5D17276E5D5 at comcast dot net> <87zjq563cz dot fsf at talisman dot default>
On 10/19/2013 05:01 AM, Richard Sandiford wrote:
I think that part of this is that neither mike or i really understand
how this stuff works anymore.
Mike Stump <firstname.lastname@example.org> writes:
+ // We optimize x < y, where y is 64 or fewer bits.
+ // We have to be careful to not allow comparison to a large positive
+ // unsigned value like 0x8000000000000000, those would be encoded
+ // with a y.len == 2.
+ if (y.precision <= HOST_BITS_PER_WIDE_INT
+ && y.len == 1)
I don't get this. If y.precision <= HOST_BITS_PER_WIDE_INT then
y.len must be 1. I realise that tree constants can be stored with
TREE_INT_CST_NUNITS > TYPE_PRECISION / HOST_BITS_PER_WIDE_INT
(so that extensions beyond TYPE_PRECISION are free). But the
wide-int code is shielded from that by the ::decompose routine.
A wide int never has len > precision / HOST_BITS_PER_WIDE_INT.
in the old version where we had precision 0, we would wait to
canonicalize a constant or a simple integer until we saw what the
precision of the other operand was. That was what precison 0 meant.
it was kind of like what you are now proposing with this new trait, but
for the reason that we actually did not know what to do than some
concern about escapement.
What i do not understand is what happens what do you get when you bring
in an integer variable that is an unsigned HOST_WIDE_INT with the top
bit set. In the precision 0 days, if the prec of the other side was 64
or less, the incoming integer took 1 hwi and if the precision was
larger, it took two hwis. The canonicalization happened late enough so
that there was never a question.
Here we are trying to do this at compile time to avoid the escape. This
is why my emails about this have continued to talk about the unsigned
HOST_WIDE_INT as a boundary case. It is clear, that if the value is a
constant, then you should be able to see at compile time if the top bit
is set, but if the value is a simple integer variable, you should still
be able to do the non escaping test as long as the type is signed
HOST_WIDE_INT or smaller.
I think that mike certainly has not captured this yet. But those are
the issues as i see them.