Is there a trick to make GCC optimize away redundant instructions? - c

Question

Compiling with gcc -mcpu=cortex-m0 -mthumb -Os
emits redundant instructions like in this illustrative example:
void memzero(void* p, int n)
{
n -= 4;
do
{
*(int*)((char*)p + n) = 0;
n -= 4;
}
while(n > 0);
}
Results in:
memzero:
movs r3, #0
subs r1, r1, #4
.L2:
str r3, [r0, r1]
subs r1, r1, #4
cmp r1, #0
bgt .L2
bx lr
Obviously, the explicit compare is essentially a nop. Is there some way to turn on more optimization to fix this?

Answer 1

Removing the compare would change the behavior of the function.
The BGT instruction jumps if Z == 0 and N == V. This is important when n overflows.
Consider calling the function with n = -2147483644 (if int is 32 bit):
memzero:
movs r3, #0
subs r1, r1, #4 ; n = -2147483648
.L2:
str r3, [r0, r1]
subs r1, r1, #4 ; n = 2147483644, Z = 0, N = 0, V = 1
;cmp r1, #0 ; (would set Z = 0, N = 0, V = 0)
bgt .L2 ; doesn't jump, even though n is positive
bx lr
The optimization works if we test for n >= 0 because there is an instruction that jumps if N == 0:
memzero:
movs r3, #0
subs r1, r1, #4
.L2:
str r3, [r0, r1]
subs r1, r1, #4
bpl .L2
bx lr
Test program
#include <stdio.h>
#include <limits.h>
__attribute__((noinline)) int with_cmp(int n) {
asm("L1:\n\t"
"subs %[n], #4\n\t"
"cmp %[n], #0\n\t"
"bgt L1"
: [n] "+r" (n));
return n;
}
__attribute__((noinline)) int without_cmp(int n) {
asm("L2:\n\t"
"subs %[n], #4\n\t"
"bgt L2"
: [n] "+r" (n));
return n;
}
int main() {
printf("with cmp: %d\nwithout cmp: %d\n", with_cmp(INT_MIN), without_cmp(INT_MIN));
}
Output:
with cmp: 0 // loops as long as n > 0
without cmp: 2147483644 // immediately returns with positive n

Answer 2

+6 nzCv nzCv
+5 nzCv nzCv
+4 nZCv nZCv
+3 Nzcv NzCv
+2 Nzcv NzCv
+1 Nzcv NzCv
+0 Nzcv NzCv
-1 NzCv NzCv
-2 NzCv NzCv
-3 NzCv NzCv
are the flag choices through the sub and cmp operations for that value of N. When N hits 4 the code tells it to stop. 4-4 = 0 stop when N <= 0.
+4 nZCv nZCv
so signed BGT Z = 0, N == V is a choice, but yes that does work for both subs and the cmp. This is a missed peephole optimization which you are free to investigate or report. I can't imagine this has not been reported to date, unless it was recently added unintentionally.
+3 Nzcv NzCv
is what is mentioned in another answer where if the comparison is changed to N != 0 then the N flag alone determines the boundary.
If you try this you can do an incrementing loop and still run into this. I believe we have seen this asked at Stack Overflow before, I don't know what to look for. Perhaps that one it didn't appear to be a possible optimization.