[Bug testsuite/102906] [12 regression] gcc.target/arm/ivopts-4.c fails since r12-4526

["clyon at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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