Re: Revisiting the TYPE_IS_SIZETYPE issue

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

On Tue, May 27, 2008 at 12:22 PM, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> You chose to not reply to
>>
>> "
>> Re-association is always possible with my idea - you just need to drop from
>> 'does not overflow' to 'may overflow' operations (thus in C speak, from
>> signed overflow semantics to unsigned overflow semantics) for the
>> expression in question.  IMHO this should allow all optimizations you
>> want from TYPE_IS_SIZETYPE types without actually having them.
>> "
>>
>> So do you agree with that?
>
> I'm not sure what the last sentence means. :-)

The starter of the discussion was the missed re-association in fold-const
which happens for signed sizetypes.  With the proposed scheme with
distinguishing only between operations that may overflow and those
we know do not we can always do re-association if we make sure to
make the re-associated operations of the may overflow kind.  This
is currently not possible because the overflow properties are tied to
the types (even to the signedness of the types) and not to individual
operations on them (and we of course cannot change the signedness
of the operands without affecting semantics - at least not without
introducing some IL bloat).

So my assertion is that if with the proposed scheme we can always
re-associate, all the optimizations that were asked for for TYPE_IS_SIZETYPE
types can be applied without making TYPE_IS_SIZETYPE types
special in the middle-end.  Just the frontend would chose the initial
kind of operation to note if overflow may happen or not.

Richard.