The current world
is actually structured so that we never ask about overflow for the two
larger classes because the reason that you used those classes was that
you never wanted to have this discussion. So if you never ask about
overflow, then it really does not matter because we are not going to
return enough bits for you to care what happened on the inside. Of
course that could change and someone could say that they wanted overflow
on widest-int. Then the comment makes sense, with revisions, unless
your review of the code that wants overflow on widest int suggests that
they are just being stupid.
But widest_int is now supposed to be at least 1 bit wider than widest
input type (unlike previously where it was double the widest input type).
So I can definitely see cases where we'd want to know whether a
widest_int * widest_int result overflows.
My point is that the widest_int * widest_int would normally be a signed
multiplication rather than an unsigned multiplication, since the extra
1 bit of precision allows every operation to be signed. So it isn't
a case of whether the top bit of a widest_int will be set, but whether
we ever reach here for widest_int in the first place. We should be
going down the sgn == SIGNED path rather than the sgn == UNSIGNED path.
widest_int can represent an all-1s value, usually interpreted as -1.
If we do go down this sgn == UNSIGNED path for widest_int then we will
instead treat the all-1s value as the maximum unsigned number, just like
for any other kind of wide int.
As far as this function goes there really is no difference between
wide_int, offset_int and widest_int. Which is good, because offset_int
and widest_int should just be wide_ints that are optimised for a specific
and fixed precision.
Thanks,
Richard
I am now seriously regretting letting richi talk me into changing the
size of the wide int buffer from being 2x of the largest mode on the
machine. It was a terrible mistake AND i would guess making it smaller
does not provide any real benefit.
The problem is that when you use widest-int (and by analogy offset int)
it should NEVER EVER overflow. Furthermore we need to change the
interfaces for these two so that you cannot even ask!!!!!! (i do not
believe that anyone does ask so the change would be small.)
There are a huge set of bugs on the trunk that are "fixed" with wide-int
because people wrote code for double-int thinking that it was infinite
precision. So they never tested the cases of what happens when the
size of the variable needed two HWIs. Most of those cases were
resolved by making passes like tree-vrp use wide-int and then being
explicit about the overflow on every operation, because with wide-int
the issue is in your face since things overflow even for 32 bit
numbers. However, with the current widest-int, we will only be safe for
add and subtract by adding the extra bit. In multiply we are exposed.
The perception is that widest-int is a good as infinite precision and no
one will ever write the code to check if it overflowed because it only
rarely happens.
