]> gcc.gnu.org Git - gcc.git/commit
AArch64: remove reliance on register allocator for simd/gpreg costing. [PR114741]
authorTamar Christina <tamar.christina@arm.com>
Thu, 18 Apr 2024 10:47:42 +0000 (11:47 +0100)
committerTamar Christina <tamar.christina@arm.com>
Thu, 18 Apr 2024 10:47:42 +0000 (11:47 +0100)
commita2f4be3dae04fa8606d1cc8451f0b9d450f7e6e6
tree3d1018e8bc4084c445da610ae9a5dd029e838276
parent82d6d385f9708fb6d5e2a2bacd003155cfc41c08
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.
gcc/config/aarch64/aarch64.md
gcc/testsuite/gcc.target/aarch64/fneg-abs_2.c
gcc/testsuite/gcc.target/aarch64/fneg-abs_4.c
gcc/testsuite/gcc.target/aarch64/pr114741.c [new file with mode: 0644]
This page took 0.062347 seconds and 5 git commands to generate.