[Bug rtl-optimization/114515] New: [14 Regression] Failure to use aarch64 lane forms after PR101523

[Bug rtl-optimization/114515] New: [14 Regression] Failure to use aarch64 lane forms after PR101523

[rsandifo at gcc dot gnu.org]

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

            Bug ID: 114515
           Summary: [14 Regression] Failure to use aarch64 lane forms
                    after PR101523
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rsandifo at gcc dot gnu.org
  Target Milestone: ---

The following test regressed on aarch64 after
g:839bc42772ba7af66af3bd16efed4a69511312ae (the fix for PR101523):

typedef float v4sf __attribute__((vector_size(16)));
void f (v4sf *ptr, float f)
{
  ptr[0] = ptr[0] * (v4sf) { f, f, f, f };
  ptr[1] = ptr[1] * (v4sf) { f, f, f, f };
}

Compiled with -O2, we previously generated:

        ldp     q1, q31, [x0]
        fmul    v1.4s, v1.4s, v0.s[0]
        fmul    v31.4s, v31.4s, v0.s[0]
        stp     q1, q31, [x0]
        ret

Now we generate:

        ldp     q1, q31, [x0]
        dup     v0.4s, v0.s[0]
        fmul    v1.4s, v1.4s, v0.4s
        fmul    v31.4s, v31.4s, v0.4s
        stp     q1, q31, [x0]
        ret

with the extra dup.

The patch is trying to avoid cases where i3 is canonicalised by contextual
information provided by i2.  But here we place a full copy of i2 into i3
(creating an instruction that is no more expensive).  This is a benefit in its
own right because the two instructions can then execute in parallel rather than
serially.  But it also means that, as here, we might be able to remove i2 with
later combinations.

Perhaps we could also check whether i3 still contains the destination of i2?

[Bug rtl-optimization/114515] [14 Regression] Failure to use aarch64 lane forms after PR101523

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |aarch64
   Target Milestone|---                         |14.0
                 CC|                            |rguenth at gcc dot gnu.org

[Bug rtl-optimization/114515] [14 Regression] Failure to use aarch64 lane forms after PR101523

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Btw, why does forwprop not do this?

[Bug rtl-optimization/114515] [14 Regression] Failure to use aarch64 lane forms after PR101523

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool <segher at gcc dot gnu.org> ---
The PR101523 fix makes sure we do not get the same I2 back, because that
violates algorithmic assumptions of combine.  Importantly, the way it was
things can be changed back time and time again, and that actually happened.
There is no "canonical form" in combine, it all depends on what little
piece of context is and is not considered what form combine prefers.  Things
can -- and DID -- oscillate.

So, what is happening here?  The "dup" here is really a "splat"?  Should the
backend have some extra define_insn or define_split, or maybe even a peephole?

[Bug rtl-optimization/114515] [14 Regression] Failure to use aarch64 lane forms after PR101523

[rsandifo at gcc dot gnu.org]

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

--- Comment #3 from Richard Sandiford <rsandifo at gcc dot gnu.org> ---
In RTL terms, the dup is vec_duplicate.  The combination is:

Trying 10 -> 13:
   10: r107:V4SF=vec_duplicate(r115:SF)
      REG_DEAD r115:SF
   13: r110:V4SF=r111:V4SF*r107:V4SF
      REG_DEAD r111:V4SF
Failed to match this instruction:
(parallel [
        (set (reg:V4SF 110 [ _2 ])
            (mult:V4SF (vec_duplicate:V4SF (reg:SF 115))
                (reg:V4SF 111 [ *ptr_6(D) ])))
        (set (reg:V4SF 107)
            (vec_duplicate:V4SF (reg:SF 115)))
    ])
Failed to match this instruction:
(parallel [
        (set (reg:V4SF 110 [ _2 ])
            (mult:V4SF (vec_duplicate:V4SF (reg:SF 115))
                (reg:V4SF 111 [ *ptr_6(D) ])))
        (set (reg:V4SF 107)
            (vec_duplicate:V4SF (reg:SF 115)))
    ])
Successfully matched this instruction:
(set (reg:V4SF 107)
    (vec_duplicate:V4SF (reg:SF 115)))
Successfully matched this instruction:
(set (reg:V4SF 110 [ _2 ])
    (mult:V4SF (vec_duplicate:V4SF (reg:SF 115))
        (reg:V4SF 111 [ *ptr_6(D) ])))
allowing combination of insns 10 and 13
original costs 8 + 20 = 28
replacement costs 8 + 20 = 28
modifying insn i2    10: r107:V4SF=vec_duplicate(r115:SF)
deferring rescan insn with uid = 10.
modifying insn i3    13: r110:V4SF=vec_duplicate(r115:SF)*r111:V4SF
      REG_DEAD r115:SF
      REG_DEAD r111:V4SF
deferring rescan insn with uid = 13.

[Bug rtl-optimization/114515] [14 Regression] Failure to use aarch64 lane forms after PR101523

[rsandifo at gcc dot gnu.org]

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

--- Comment #4 from Richard Sandiford <rsandifo at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> Btw, why does forwprop not do this?
Not 100% sure (I wasn't involved in choosing the current heuristics).  But
fwprop can propagate across blocks, so there is probably more risk of
increasing register pressure.

[Bug rtl-optimization/114515] [14 Regression] Failure to use aarch64 lane forms after PR101523

[rsandifo at gcc dot gnu.org]

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

--- Comment #5 from Richard Sandiford <rsandifo at gcc dot gnu.org> ---
For the record, the associated new testsuite failures are:

FAIL: gcc.target/aarch64/ashltidisi.c scan-assembler-times asr 3
FAIL: gcc.target/aarch64/asimd-mull-elem.c scan-assembler-times
\\s+fmul\\tv[0-9]+\\.4s, v[0-9]+\\.4s, v[0-9]+\\.s\\[0\\] 4
FAIL: gcc.target/aarch64/asimd-mull-elem.c scan-assembler-times
\\s+mul\\tv[0-9]+\\.4s, v[0-9]+\\.4s, v[0-9]+\\.s\\[0\\] 4
FAIL: gcc.target/aarch64/ccmp_3.c scan-assembler-not \tcbnz\t
FAIL: gcc.target/aarch64/pr100056.c scan-assembler-times \\t[us]bfiz\\tw[0-9]+,
w[0-9]+, 11 2
FAIL: gcc.target/aarch64/pr100056.c scan-assembler-times \\tadd\\tw[0-9]+,
w[0-9]+, w[0-9]+, uxtb\\n 2
FAIL: gcc.target/aarch64/pr108840.c scan-assembler-not and\\tw[0-9]+, w[0-9]+,
31
FAIL: gcc.target/aarch64/pr112105.c scan-assembler-not \\tdup\\t
FAIL: gcc.target/aarch64/pr112105.c scan-assembler-times
(?n)\\tfmul\\t.*v[0-9]+\\.s\\[0\\]\\n 2
FAIL: gcc.target/aarch64/rev16_2.c scan-assembler-times rev16\\tx[0-9]+ 2
FAIL: gcc.target/aarch64/vaddX_high_cost.c scan-assembler-not dup\\t
FAIL: gcc.target/aarch64/vmul_element_cost.c scan-assembler-not dup\\t
FAIL: gcc.target/aarch64/vmul_high_cost.c scan-assembler-not dup\\t
FAIL: gcc.target/aarch64/vsubX_high_cost.c scan-assembler-not dup\\t
FAIL: gcc.target/aarch64/sve/pr98119.c scan-assembler \\tand\\tx[0-9]+,
x[0-9]+, #?-31\\n
FAIL: gcc.target/aarch64/sve/pred-not-gen-1.c scan-assembler-not \\tbic\\t
FAIL: gcc.target/aarch64/sve/pred-not-gen-1.c scan-assembler-times
\\tnot\\tp[0-9]+\\.b, p[0-9]+/z, p[0-9]+\\.b\\n 1
FAIL: gcc.target/aarch64/sve/pred-not-gen-4.c scan-assembler-not \\tbic\\t
FAIL: gcc.target/aarch64/sve/pred-not-gen-4.c scan-assembler-times
\\tnot\\tp[0-9]+\\.b, p[0-9]+/z, p[0-9]+\\.b\\n 1
FAIL: gcc.target/aarch64/sve/var_stride_2.c scan-assembler-times
\\tubfiz\\tx[0-9]+, x2, 10, 16\\n 1
FAIL: gcc.target/aarch64/sve/var_stride_2.c scan-assembler-times
\\tubfiz\\tx[0-9]+, x3, 10, 16\\n 1
FAIL: gcc.target/aarch64/sve/var_stride_4.c scan-assembler-times
\\tsbfiz\\tx[0-9]+, x2, 10, 32\\n 1
FAIL: gcc.target/aarch64/sve/var_stride_4.c scan-assembler-times
\\tsbfiz\\tx[0-9]+, x3, 10, 32\\n 1

[Bug rtl-optimization/114515] [14 Regression] Failure to use aarch64 lane forms after PR101523

[law at gcc dot gnu.org]

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

Jeffrey A. Law <law at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
                 CC|                            |law at gcc dot gnu.org

[Bug rtl-optimization/114515] [14 Regression] Failure to use aarch64 lane forms after PR101523

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P1
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-04-02
             Status|UNCONFIRMED                 |NEW

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Note I think given the offending rev fixed a very old bug we should eventually
revert the fix and rework it during next stage1.  This was at least
unexpectedly big fallout AFAIU.

[Bug rtl-optimization/114515] [14 Regression] Failure to use aarch64 lane forms after PR101523

[rdapp at gcc dot gnu.org]

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

Robin Dapp <rdapp at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ewlu at rivosinc dot com,
                   |                            |rdapp at gcc dot gnu.org

--- Comment #7 from Robin Dapp <rdapp at gcc dot gnu.org> ---
There is some riscv fallout as well.  Edwin has the details.

[Bug rtl-optimization/114515] [14 Regression] Failure to use aarch64 lane forms after PR101523

[ewlu at rivosinc dot com]

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

--- Comment #8 from Edwin Lu <ewlu at rivosinc dot com> ---
(In reply to Robin Dapp from comment #7)
> There is some riscv fallout as well.  Edwin has the details.

I haven't done an in depth analysis but the full list of new riscv scan-dump
failures can be found here:
https://github.com/patrick-rivos/gcc-postcommit-ci/issues/694

[Bug rtl-optimization/114515] [14 Regression] Failure to use aarch64 lane forms after PR101523

[law at gcc dot gnu.org]

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

--- Comment #9 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Thanks for that info Edwin -- my tester flagged them too and mentally I'd
figured it was most likely the combiner change.

[Bug rtl-optimization/114515] [14 Regression] Failure to use aarch64 lane forms after PR101523

[tnfchris at gcc dot gnu.org]

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

Tamar Christina <tnfchris at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tnfchris at gcc dot gnu.org
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=114575

--- Comment #10 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
This has also broken our addressing modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114575

[Bug rtl-optimization/114515] [15 Regression] Failure to use aarch64 lane forms after PR101523

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|14.0                        |15.0
            Summary|[14 Regression] Failure to  |[15 Regression] Failure to
                   |use aarch64 lane forms      |use aarch64 lane forms
                   |after PR101523              |after PR101523

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
Reverted for GCC 14 but will re-appear for GCC 15.