Re: Revisiting the TYPE_IS_SIZETYPE issue

[Eric Botcazou <ebotcazou at adacore dot com>]

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

I think it depends on what "we know do not" means.  If this is a property that 
needs to be preserved, it's no different from the current situation since it 
will also prevent reassociation.

But, more fundamentally, you seem to be still proposing a binary world, i.e 
"may overflow" for C unsigned semantics and "does not overflow" for C signed 
semantics.  How would the TYPE_IS_SIZETYPE semantics fit exactly?  It cannot 
be reduced to either of the above 2 so you need either a third state or to 
have parameterizable transition rules between the 2 states.

> So my idea (I have this for some time now, but there's always lack
> of time to implement it ...) is to make the existing tree codes
> 'may overflow' operations and introduce new tree code variants
> with the 'does not overflow' semantics.  This way we conservatively
> preserve 'may overflow' in legacy code.
>
> The middle-end would then _never_ look at the types to determine
> overflow behavior, but only at the properties of the operands involved.

OK, I think that this would be a net improvement over what we have now but its 
interaction with the TYPE_IS_SIZETYPE semantics is still a bit unclear to me.

-- 
Eric Botcazou