Revisiting the TYPE_IS_SIZETYPE issue

[Richard Guenther]

On Tue, May 27, 2008 at 11:07 AM, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> Well, this goes back to the question what TYPE_IS_SIZETYPE semantics
>> are ;)  I guess it would be a sort-of "sticky" 'does not overflow'
>> flag?  That is even after any possible re-association no operation does
>> overflow?
>
> Yes.
>
>> What happens if you re-associate  (A +/o B) +/s C  (the first +/o might
>> overflow, the second +/s is the "sticky" one)?
>
> I presume that the FE should make sure this cannot happen, but /s should trump
> anything else in the end.
>
>> From the past discussion we are still waiting for a testcase where the
>> reassoication in question (the one that initially provoked all these
>> discussions) matters.
>
> Well, if you think that the transformation at stake in fold-const.c is totally
> useless, why not simply get rid of the entire code?

Sure, why not.  But getting rid of these recursive foldings (also like
extract_muldiv and friends) requires to open-code the two or three
useful flat transformations - those that are useful if you combine
two gimple expressions.

Did you even try my initial suggestion from the last discussion to
make TYPE_IS_SIZETYPEs TYPE_OVERFLOW_WRAPs?  As
said in the previous discussion you run into the (optimization) differences
compared to C because your sizetype is signed (and thus
TYPE_OVERFLOW_UNDEFINED).

And we still didn't get a testcase, so rely on you to even try what we
suggest.

Richard.