http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59999
--- Comment #22 from Paulo J. Matos <pa...@matos-sorge.com> ---
After some thought, I am concluding this cannot actually be optimized and that
GCC 4.5.4 was better because it was taking advantage of an undefined behaviour
that doesn't exist.
The thought process is as follows. The whole process has to do with this type
of loop:
void foo (int loopCount)
{
short i;
for (i = 0; (int)i < loopCount; i++)
...
}
GCC 4.5.4 was assuming i++ could have undefined behaviour and the increment was
done in type short. Then i was promoted to int through a sign_extend and
compared to loopCount. This undefined behaviour allows GCC 4.5.4 to generate an
int scev for the loop.
In GCC 4.8 or later (haven't tested with 4.6 or 4.7), i++ is known not to have
undefined behaviour. i++ due to C integer promotion rules is: i = (short)
((int) i + 1). GCC validly simplifies to i = (short) ((unsigned short)i + 1).
This is then sign extended to int for comparison. GCC cannot generate an int
scev because it's not simple: (int) (short) {1, +, 1}_1.
This can validly loop forever if loopCount > SHORT_MAX.
For example, is loopCount is SHORT_MAX + 1, then when i reaches SHORT_MAX and
is incremented by one the addition is fine because is done in (unsigned short)
and then truncated using modulo 2 (implementation defined behaviour) to short,
therefore never reaching loopCount and looping forever.
In RTL we get the following sequence:
r4:SI <- [loopCount]
r0:HI <- 0
code label...
...
r2:HI <- r1:HI + 1
r3:SI <- sign_extend r2:HI
p0:BI <- r3:SI < r4:SI
loop to code label if p0:BI
I was tempted to simplify this to:
r4:SI <- [loopCount]
r0:SI <- 0
code label...
...
r2:SI <- r1:SI + 1
p0:BI <- r2:SI < r4:SI
loop to code label if p0:BI
However this will never have an infinite loop behaviour if r4:SI == SHORT_MAX,
therefore I think that at least in this case this cannot be optimized.
I am tempted to close the bug report. Richard?
