http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59371
--- Comment #5 from Maciej W. Rozycki <ma...@linux-mips.org> ---
(In reply to Andrew Pinski from comment #4)
> Well that corrects how i++ is done.
Old MIPS assembly code produced was AFAICT correct. The loop termination
condition was expressed as:
bne $3,$6,$L3
that represented (i != c) rather than (i < c), but we start `i' from 0
and increment by one at a time, so both expressions are equivalent in
this context.
Here I believe the following C language standard clause applies[1]:
"Otherwise, if the operand that has unsigned integer type has rank
greater or equal to the rank of the type of the other operand, then the
operand with signed integer type is converted to the type of the operand
with unsigned integer type."
so for both operands the expression is supposed to use the "unsigned
short" type, that is 16-bit on the MIPS target. There are no 16-bit ALU
operations defined in the MIPS architecture though, so at the assembly
(and therefore machine-level) level both `c' and `i' were sign-extended
to 32-bits:
andi $5,$5,0xffff
seh $6,$5
and:
seh $3,$3
respectively (of course ANDI is redundant here, there's no need to
zero-extend before sign-extending, SEH does not require it), before the
BNE comparison quoted above was made. That correctly mimicked 16-bit
operations required by the language here (of course zero-extension of
both `c' and `i' would do as well).
Now after the change `c' is zero-extended only (no sign-extension
afterwards):
andi $5,$5,0xffff
while `i' is still sign-extended:
seh $3,$3
Then the loop termination condition is expressed as:
slt $6,$3,$5
bne $6,$0,$L3
instead. Notice the SLT instruction, that accurately represents the
(i < c) termination condition, however using *signed* arithmetic. Which
means that for `c' equal e.g. to 32768 the loop will never terminate. I
believe this is not what the clause of the C language standard quoted
above implies. For unsigned arithmetic SLTU would have to be used
instead.
So it looks to me like the performance regression merely happens to be
a visible sign of a bigger correctness problem. Have I missed anything?
[1] "Programming languages -- C", ISO/IEC 9899:1999(E), Section 6.3.1.8
"Usual arithmetic conversions".
