[Bug target/113542] [14 Regression] gcc.target/arm/bics_3.c regression after change for pr111267

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

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

Maxim Kuvyrkov <mkuvyrkov at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rearnsha at gcc dot gnu.org
           Assignee|mkuvyrkov at gcc dot gnu.org       |unassigned at gcc dot gnu.org

--- Comment #4 from Maxim Kuvyrkov <mkuvyrkov at gcc dot gnu.org> ---
Reply from Richard Earnshaw on gcc-patches@ to my patch to make the testcase
accept both "bic" and "bics" instructions:

The test was added (r6-823-g0454e698401a3e) specifically to check that a BICS
instruction was being generated.  Whether or not that is right is somewhat
debatable, but this change seems to be papering over a different issue.

Either we should generate BICS, making this change incorrect, or we should
disable the test for thumb code on the basis that this isn't really a win.

But really, we should fix the compiler to do better here.  We really want
something like

        BICS  r0, r0, r1  // r0 is 0 or non-zero
        MOVNE r0, #1      // convert all non-zero to 1

in Arm state (ie using the BICS instruction to set the result to zero); and in
thumb2, perhaps something like:

        BICS  r0, r0, r1
        IT    ne
        MOVNE r0, #1

or maybe even better:

        BIC  r0, r0, r1
        SUBS r1, r0, #1
        SBC  r0, r0, r1

which is slightly better than BICS because SUBS breaks a condition-code chain
(all the flag bits are set).

There are similar quality issues for other NE(arith-op, 0) cases; we just don't
have tests for those.