Re: Serious performance regression -- some tree optimizer questions

[Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>]

Hello,

> The problem is that this is not just an inadequacy of the current code,
> it is a fundamental problem:  you *cannot* deduce I1+1 doesn't overflow
> because it is simply not *true* that it is a logical consequence of all
> known facts.  In theory, I1+1 could overflow for the initial value of
> N == INT_MIN; and at the level of the GENERIC tree passed to the
> mid-end, there is nothing that allows to conclude that this case
> cannot happen ...
> 
> This is why I would suggest that we finally do make use of the fact that
> signed overflow represents undefined behaviour in some languages.  We
> couldn't at the RTL level because there is no reliable way to distinguish
> between signed and unsigned arithmetic there.  But at the tree level,
> if the induction step is performed using arithmetic on a signed data
> type, and neither -fwrapv nor -ftrapv is in effect, we could simply
> allow the scalar evolution mechanism to conclude that this variable
> does not overflow.
> 
> What do you think?

I have considered this (I even started writing this a few weeks ago).
The problem is that it is a bit more complicated that one would expect.
I forgot the details, but in general I reached the conclusion that
the current scev code so messy that I would either have to perform
a major cleanup of it (very close to rewriting it from scratch),
or hack up something I would not really believe to be correct.

Zdenek