Re: Revisiting the TYPE_IS_SIZETYPE issue

[Ian Lance Taylor <iant at google dot com>]

"Richard Guenther" <richard.guenther@gmail.com> writes:

> I think that rather than trying to special case sizetype again too much
> we should try to sort out a plan on how to move the
> TYPE_OVERFLOW_WRAPS and TYPE_OVERFLOW_UNDEFINED
> semantics away from types down to the operators - which is needed
> anyway for LTO of TUs with different setting of -fwrapv for example.
> This would also allow passes like VRP to keep which expressions
> may overflow and thus enable further optimizations.
>
> Rather than the two flags TYPE_OVERFLOW_WRAPS and
> TYPE_OVERFLOW_UNDEFINED we should make it more explicit
> (and conveniently match intended sizetype behavior) and distinguish
> between operations that may overflow and operations that we know
> do not ('does not overflow' is a valid interpretation of 'undefined overflow').

What about -ftrapv?  Add another set of tree codes?  Or just get rid
of it?

If I understand this proposal, it would eliminate the distinction
between -fwrapv and -fno-strict-overflow for integer types (tests of
TYPE_OVERFLOW_WRAPS for a signed type are typically cases where the
behaviour differs: TYPE_OVERFLOW_WRAPS is true for -fwrapv but not for
-fno-strict-overflow).  This is probably OK.

I've been thinking that additional flags on the tree would be
preferable to new tree codes.  It's true as you point out downthread
that this would require changing fold.  But it wouldn't require
changing lots of other places.  There aren't that many calls to
fold_binary and friends.  There are many more uses of PLUS_EXPR and
friends.  It seems to me that it would be simpler to add a flags
parameter to fold_binary.

I agree that this general approach, however it is implemented, should
permit us to eliminate the special casing of sizetype.  It will push
the problem back to the frontend.

Ian