Kenneth Zadeck <zadeck@naturalbridge.com> writes:
it is certainly true that in order to do an unbounded set of operations,
you would have to check on every operation. so my suggestion that we
should remove the checking from the infinite precision would not support
this. but the reality is that there are currently no places in the
compiler that do this.
Currently all of the uses of widest-int are one or two operations, and
the style of code writing is that you do these and then you deal with
the overflow at the time that you convert the widest-int to a tree. I
think that it is important to maintain the style of programming where
for a small finite number of computations do not need to check until
they convert back.
The problem with making the buffer size so tight is that we do not have
an adequate reserves to allow this style for any supportable type.
I personally think that 2x + some small n is what we need to have.
i am not as familiar with how this is used (or to be used when all of
the offset math is converted to use wide-int), but there appear to be
two uses of multiply. one is the "harmless" mult by 3" and the other
is where people are trying to compute the size of arrays. These last
operations do need to be checked for overflow. The question here is
do you want to force those operations to overflow individually or do you
want to check when you convert out. Again, i think 2x + some small
number is what we might want to consider.
It's a fair question, but personally I think checking for overflow
on the operation is much more robust. Checking on conversion doesn't
allow you to stop thinking about overflow, it just changes the way you
think about it: rather than handling explicit overflow flags, you have
to remember to ask "is the range of the unconverted result within the
range of widest_int", which I bet it is something that would be easily
forgotten once widest_int & co. are part of the furniture.
E.g. the SPARC operation (picked only because I remember it):
for (i = 0; i < VECTOR_CST_NELTS (arg0); ++i)
{
tree e0 = VECTOR_CST_ELT (arg0, i);
tree e1 = VECTOR_CST_ELT (arg1, i);
bool neg1_ovf, neg2_ovf, add1_ovf, add2_ovf;
tmp = wi::neg (e1, &neg1_ovf);
tmp = wi::add (e0, tmp, SIGNED, &add1_ovf);
if (wi::neg_p (tmp))
tmp = wi::neg (tmp, &neg2_ovf);
else
neg2_ovf = false;
result = wi::add (result, tmp, SIGNED, &add2_ovf);
overflow |= neg1_ovf | neg2_ovf | add1_ovf | add2_ovf;
}
gcc_assert (!overflow);
return wide_int_to_tree (rtype, result);
seems pretty natural. If instead it was modelled as a widest_int
chain without overflow then it would be less obviously correct.
Thanks,
Richard