Re: Revisiting the TYPE_IS_SIZETYPE issue

["Richard Guenther" <richard dot guenther at gmail dot com>]

On Tue, May 27, 2008 at 8:49 AM, Ian Lance Taylor <iant@google.com> wrote:
> "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?

I would 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.

One goal would be to make things simpler again, and less error-prone.

> 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.

It is not only fold - with tuples we have the operation decomposed, so
you need two sets of flags, one for regular tree expressions and one
for tuple expressions.  And one for the SCCVN IL, etc.

Eventually having the flags on the tree code itself sounds like the
most convenient way.  But of course that leaves out the implementation
details here.

For floating point operations (that also use PLUS_EXPR ...) there are
many more flags we probably need to carry somehow - basically at
least if the operation may trap and the rounding mode involved.  The
trapping bit could be shared to implement -ftrapv support, but in
total we still would have at least four variants (2 bits, rounding
mode and overflow can share one) of PLUS_EXPR.

The current tree-code has 16 bits reserved of which 9 are used
for distinct tree-codes - so there would be space to fit some flag
bits in there and we'd have sth like

#define TREE_CODE_RAW(NODE) ((NODE)->base.code)
#define TREE_CODE(NODE) ((enum tree_code) (NODE)->base.code & 511)
#define TREE_CODE_FLAGS(NODE) ((NODE)->base.code)

> 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.

Yes.

Richard.