[Bug testsuite/103298] [12 regressions] regressions on arm after r12-5301

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103298

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|rguenth at gcc dot gnu.org         |unassigned at gcc dot gnu.org
                 CC|                            |ramana at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org
             Status|ASSIGNED                    |NEW
          Component|tree-optimization           |testsuite

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Christophe Lyon from comment #0)
> r12-5301 is causing regressions on some arm targets:
> 
> arm-none-linux-gnueabi -march=armv7-a -mthumb:
> FAIL: gcc.target/arm/pr42093.c scan-assembler-not tbb

The testcase seems to be for a wrong-code issue but was implemented as
scan-assembler one which is now seemingly dependent on switch expansion
heuristics.

Previously we got

        ldr     pc, [r6, r2, lsl #2]
        .align  2
.L6:
        .word   .L14+1
...

but now

        cmp     r2, #50
        bhi     .L1
        tbb     [pc, r2]
.L5:
        .byte   (.L7-.L5)/2
...

which  looks more optimal to me.  So the testcase is simply bogus?  Defering
to ARM folks.


> FAIL: gcc.target/arm/pr43920-2.c object-size text <= 54

--- a/pr43920-2.s       2021-11-18 10:32:22.975744703 +0100
+++ b/pr43920-2.s       2021-11-18 10:31:56.763399263 +0100
@@ -34,18 +34,19 @@
        mov     r0, r7
        bl      lseek
        adds    r2, r4, #1
-       beq     .L4
-       adds    r3, r0, #1
        beq     .L1
+       adds    r3, r0, #1
+       beq     .L4
        subs    r0, r0, r4
        beq     .L4
        str     r4, [r6]
+       movs    r4, #0
        str     r0, [r5]
-       movs    r0, #0
 .L1:
+       mov     r0, r4
        pop     {r3, r4, r5, r6, r7, pc}
 .L4:
-       mov     r0, #-1
+       mov     r4, #-1
        b       .L1

well ...  .optimized change:

--- a/pr43920-2.c.250t.optimized        2021-11-18 10:32:22.951744385 +0100
+++ b/pr43920-2.c.250t.optimized        2021-11-18 10:31:56.739398949 +0100
@@ -39,7 +39,7 @@
   *length__13(D) = length_10;

   <bb 6> [local count: 1073741824]:
-  # _2 = PHI <end_9(3), 0(5), start_7(2), -1(4)>
+  # _2 = PHI <start_7(2), 0(5), end_9(3), -1(4)>
   return _2;

 }

-Coalesce list: (2)_2 & (9)end_9 [map: 0, 3] : Success -> 0
-Coalesce list: (2)_2 & (7)start_7 [map: 0, 2] : Fail due to conflict
+Coalesce list: (2)_2 & (7)start_7 [map: 0, 2] : Success -> 0
+Coalesce list: (2)_2 & (9)end_9 [map: 0, 3] : Fail due to conflict

-Inserting a partition copy on edge BB2->BB6 : PART.1 = PART.3
+Inserting a partition copy on edge BB3->BB6 : PART.1 = PART.3

looks like a fuss to me (fragile testcase).  Not sure if it is worth trying
to for example sort PHI args after SSA name version for increased stability,
at RTL expansion time we have exactly the same number of copies but I guess
(just guess) that at RA time things start to differ.

Again, ARM folks - please allow for the extra reg copy.

> arm-none-linux-gnueabi -march=armv5t -mthumb:
> FAIL: gcc.dg/tree-ssa/if-to-switch-3.c scan-tree-dump iftoswitch "Condition
> chain with [^\n\r]* BBs transformed into a switch statement."

should be fixed now.