https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906
--- Comment #9 from Christophe Lyon <clyon at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #7)
> > then size ivopts-4.o:
> > text data bss dec hex filename
> > 38 0 0 38 26 ivopts-4.o
> > where the testcase expects text <= 36
>
> Ohhhhh, this is an object size regression? This test seems very fragile.
> Jump threading will alter code size, so any change in the threading rules
> will likely have an effect on code size. I suggest you add
> -fno-thread-jumps to the test and adjust the object-size test accordingly.
I tried that, it doesn't change the generated code.
> This is a testsuite regression that must be fixed by the target maintainers,
> not a middle-end or tree-optimization regression. I've marked it as so.
>
Before your changes, we generated (with -mthumb
-march=armv7-a+mp+sec+neon-fp16)
tr2:
push {r4, r5, r6, lr}
cmp r1, #0
mov r4, r0
ble .L4
add r5, r0, r1, lsl #2
movs r6, #0
.L3:
mov r0, r4
adds r4, r4, #4
bl foo
cmp r4, r5
add r6, r6, r0
bne .L3
.L1:
mov r0, r6
pop {r4, r5, r6, pc}
.L4:
movs r6, #0
b .L1
After the jump-threading change (r12-4526):
tr2:
push {r4, r5, r6, lr}
cmp r1, #0
mov r4, r0
ble .L5
add r5, r0, r1, lsl #2
movs r6, #0
.L3:
cmp r4, r5
bne .L4
.L1:
mov r0, r6
pop {r4, r5, r6, pc}
.L4:
mov r0, r4
adds r4, r4, #4
bl foo
add r6, r6, r0
b .L3
.L5:
movs r6, #0
b .L1
