[Bug target/114741] [14 regression] aarch64 sve: unnecessary fmov for scalar int bit operations

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

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

--- Comment #9 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tamar Christina <tnfchris@gcc.gnu.org>:

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

commit r14-10014-ga2f4be3dae04fa8606d1cc8451f0b9d450f7e6e6
Author: Tamar Christina <tamar.christina@arm.com>
Date:   Thu Apr 18 11:47:42 2024 +0100

    AArch64: remove reliance on register allocator for simd/gpreg costing.
[PR114741]

    In PR114741 we see that we have a regression in codegen when SVE is enable
where
    the simple testcase:

    void foo(unsigned v, unsigned *p)
    {
        *p = v & 1;
    }

    generates

    foo:
            fmov    s31, w0
            and     z31.s, z31.s, #1
            str     s31, [x1]
            ret

    instead of:

    foo:
            and     w0, w0, 1
            str     w0, [x1]
            ret

    This causes an impact it not just codesize but also performance.  This is
caused
    by the use of the ^ constraint modifier in the pattern <optab><mode>3.

    The documentation states that this modifier should only have an effect on
the
    alternative costing in that a particular alternative is to be preferred
unless
    a non-psuedo reload is needed.

    The pattern was trying to convey that whenever both r and w are required,
that
    it should prefer r unless a reload is needed.  This is because if a reload
is
    needed then we can construct the constants more flexibly on the SIMD side.

    We were using this so simplify the implementation and to get generic cases
such
    as:

    double negabs (double x)
    {
       unsigned long long y;
       memcpy (&y, &x, sizeof(double));
       y = y | (1UL << 63);
       memcpy (&x, &y, sizeof(double));
       return x;
    }

    which don't go through an expander.
    However the implementation of ^ in the register allocator is not according
to
    the documentation in that it also has an effect during coloring.  During
initial
    register class selection it applies a penalty to a class, similar to how ?
does.

    In this example the penalty makes the use of GP regs expensive enough that
it no
    longer considers them:

        r106: preferred FP_REGS, alternative NO_REGS, allocno FP_REGS
    ;;        3--> b  0: i   9 r106=r105&0x1
        :cortex_a53_slot_any:GENERAL_REGS+0(-1)FP_REGS+1(1)PR_LO_REGS+0(0)
                             PR_HI_REGS+0(0):model 4

    which is not the expected behavior.  For GCC 14 this is a conservative fix.

    1. we remove the ^ modifier from the logical optabs.

    2. In order not to regress copysign we then move the copysign expansion to
       directly use the SIMD variant.  Since copysign only supports floating
point
       modes this is fine and no longer relies on the register allocator to
select
       the right alternative.

    It once again regresses the general case, but this case wasn't optimized in
    earlier GCCs either so it's not a regression in GCC 14.  This change gives
    strict better codegen than earlier GCCs and still optimizes the important
cases.

    gcc/ChangeLog:

            PR target/114741
            * config/aarch64/aarch64.md (<optab><mode>3): Remove ^ from alt 2.
            (copysign<GPF:mode>3): Use SIMD version of IOR directly.

    gcc/testsuite/ChangeLog:

            PR target/114741
            * gcc.target/aarch64/fneg-abs_2.c: Update codegen.
            * gcc.target/aarch64/fneg-abs_4.c: xfail for now.
            * gcc.target/aarch64/pr114741.c: New test.