[Bug target/94595] New: gcc.target/arm/thumb2-cond-cmp-*.c fail for cortex-m

[Bug target/94595] New: gcc.target/arm/thumb2-cond-cmp-*.c fail for cortex-m

[clyon at gcc dot gnu.org]

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

            Bug ID: 94595
           Summary: gcc.target/arm/thumb2-cond-cmp-*.c fail for cortex-m
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

I've noticed that gcc.target/arm/thumb2-cond-cmp-*.c fail when targeting
cortex-M CPUs.

For thumb2-cond-cmp-1.c, the code generated at svn r196196 for cortex-m3 was:
f:
        cmp     r1, #45
        it      ne
        cmpne   r0, #43
        ite     ne
        movne   r0, #0
        moveq   r0, #1
        bx      lr

Since r204778, we generate:
f:
        cmp     r0, #43 @ 8     [c=4 l=2]  *arm_cmpsi_insn/0
        ittte   ne
        subne   r0, r1, #45     @ 66    [c=8 l=6]  *p *arm_subsi3_insn/5
        clzne   r0, r0  @ 67    [c=8 l=6]  *p clzsi2
        lsrne   r0, r0, #5      @ 68    [c=8 l=6]  *p *arm_shiftsi3/1
        moveq   r0, #1  @ 5     [c=8 l=6]  *p *thumb2_movsi_insn/1
        bx      lr      @ 61    [c=8 l=4]  *thumb2_return


but using -mcpu=cortex-a9 generates:
f:
        cmp     r1, #45 @ 26    [c=20 l=6]  *cmp_ior/0
        it      ne
        cmpne   r0, #43
        ite     eq
        moveq   r0, #1  @ 29    [c=8 l=6]  *p *thumb2_movsi_insn/1
        movne   r0, #0  @ 30    [c=8 l=6]  *p *thumb2_movsi_insn/1
        bx      lr      @ 33    [c=8 l=4]  *thumb2_return


I'm not quite sure about the intent of the test (the comment says "Use
conditional compare"): strictly speaking, the cortex-m3 version does not use
conditional compares, but I'm wondering whether subne can be considered as a
conditional compare? If so, then only the testcases need an update in the
scan-assembler directive.

Or do we want to enforce the use of conditional compare instructions?

FWIW, these tests were introducted in 2011 (r178102) and started failing for
cortex-m in 2013 (r204778), does anyone remember the context?

[Bug target/94595] gcc.target/arm/thumb2-cond-cmp-*.c fail for cortex-m

[clyon at gcc dot gnu.org]

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

--- Comment #1 from Christophe Lyon <clyon at gcc dot gnu.org> ---
For thumb2-cond-cmp-4.c (if ( (i >= '+') ? (j <= '-') : 1) ) we generate:

* cortex-m0:
f:
        cmp     r0, #42
        ble     .L3
        movs    r3, #45
        movs    r2, #0
        lsrs    r0, r1, #31
        cmp     r3, r1
        adcs    r0, r0, r2
.L1:
        bx      lr
.L3:
        movs    r0, #1
        b       .L1

* cortex-m3:
f:
        cmp     r0, #42
        ble     .L3
        cmp     r1, #45
        ite     gt
        movgt   r0, #0
        movle   r0, #1
        bx      lr
.L3:
        movs    r0, #1
        bx      lr

* cortex-m7:
f:
        cmp     r1, #45
        it      gt
        cmpgt   r0, #42
        ite     le
        movle   r0, #1
        movgt   r0, #0
        bx      lr

* cortex-a9:
f:
        cmp     r1, #45
        it      gt
        cmpgt   r0, #42
        ite     le
        movle   r0, #1
        movgt   r0, #0
        bx      lr

[Bug target/94595] gcc.target/arm/thumb2-cond-cmp-*.c fail for cortex-m

[clyon at gcc dot gnu.org]

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

Christophe Lyon <clyon at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2020-09-08
           Assignee|unassigned at gcc dot gnu.org      |clyon at gcc dot gnu.org

[Bug target/94595] gcc.target/arm/thumb2-cond-cmp-*.c fail for cortex-m

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Christophe Lyon <clyon@gcc.gnu.org>:

https://gcc.gnu.org/g:ef11f5b37b0a62dbad9ed37613a3799dc98f6f8b

commit r11-3564-gef11f5b37b0a62dbad9ed37613a3799dc98f6f8b
Author: Christophe Lyon <christophe.lyon@linaro.org>
Date:   Mon Sep 7 14:53:38 2020 +0000

    arm: [testsuite] Skip thumb2-cond-cmp tests on Cortex-M [PR94595]

    Since r204778 (g571880a0a4c512195aa7d41929ba6795190887b2), we favor
    branches over IT blocks on Cortex-M. As a result, instead of
    generating two nested IT blocks in thumb2-cond-cmp-[1234].c, we
    generate either a single IT block, or use branches depending on
    conditions tested by the program.

    Since this was a deliberate change and the tests still pass as
    expected on Cortex-A, this patch skips them when targetting
    Cortex-M. The avoids the failures on Cortex M3, M4, and M33.  This
    patch makes the testcases unsupported on Cortex-M7 although they pass
    in this case because this CPU has different branch costs.

    I tried to relax the scan-assembler directives using eg. cmpne|subne
    or cmpgt|ble but that seemed fragile.

    2020-09-07  Christophe Lyon  <christophe.lyon@linaro.org>

            gcc/testsuite/
            PR target/94595
            * gcc.target/arm/thumb2-cond-cmp-1.c: Skip if arm_cortex_m.
            * gcc.target/arm/thumb2-cond-cmp-2.c: Skip if arm_cortex_m.
            * gcc.target/arm/thumb2-cond-cmp-3.c: Skip if arm_cortex_m.
            * gcc.target/arm/thumb2-cond-cmp-4.c: Skip if arm_cortex_m.

[Bug target/94595] gcc.target/arm/thumb2-cond-cmp-*.c fail for cortex-m

[clyon at gcc dot gnu.org]

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

Christophe Lyon <clyon at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #3 from Christophe Lyon <clyon at gcc dot gnu.org> ---
Fixed on trunk