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] int_traits <tree>

On 10/19/2013 05:01 AM, Richard Sandiford wrote:
Mike Stump <> 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
(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.

I think that part of this is that neither mike or i really understand how this stuff works anymore.

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.

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