[Bug tree-optimization/101506] New: [12 Regression] gcc.target/aarch64/vect-fmaxv-fminv-compile.c fail after gcc-12-2292-g1dd3f2109585

[Bug tree-optimization/101506] New: [12 Regression] gcc.target/aarch64/vect-fmaxv-fminv-compile.c fail after gcc-12-2292-g1dd3f2109585

[mkuvyrkov at gcc dot gnu.org]

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

            Bug ID: 101506
           Summary: [12 Regression]
                    gcc.target/aarch64/vect-fmaxv-fminv-compile.c fail
                    after gcc-12-2292-g1dd3f2109585
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mkuvyrkov at gcc dot gnu.org
  Target Milestone: ---

On aarch64-linux-gnu I get 2 new failures after
===
commit 1dd3f21095858fbfd3e28a149578d5fb67e75f95
Author: Richard Biener <rguenther@suse.de>
Date:   Tue Jul 13 13:59:15 2021 +0200

   Support reduction def re-use for epilogue with different vector size

   The following adds support for re-using the vector reduction def
   from the main loop in vectorized epilogue loops on architectures
   which use different vector sizes for the epilogue.  That's only
   x86 as far as I am aware.
===

                === gcc tests ===

Running gcc.target/aarch64/aarch64.exp ...
PASS: gcc.target/aarch64/vect-fmaxv-fminv-compile.c (test for excess errors)
FAIL: gcc.target/aarch64/vect-fmaxv-fminv-compile.c scan-assembler fminnmv
FAIL: gcc.target/aarch64/vect-fmaxv-fminv-compile.c scan-assembler fmaxnmv
PASS: gcc.target/aarch64/vect-fmaxv-fminv-compile.c scan-assembler fminnmp
PASS: gcc.target/aarch64/vect-fmaxv-fminv-compile.c scan-assembler fmaxnmp

[Bug tree-optimization/101506] [12 Regression] gcc.target/aarch64/vect-fmaxv-fminv-compile.c fail after gcc-12-2292-g1dd3f2109585

[mkuvyrkov at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #1 from Maxim Kuvyrkov <mkuvyrkov at gcc dot gnu.org> ---
Hi Richard,

Would you please take a look?

[Bug testsuite/101506] [12 Regression] gcc.target/aarch64/vect-fmaxv-fminv-compile.c fail after gcc-12-2292-g1dd3f2109585

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|tree-optimization           |testsuite
             Target|                            |aarch64
   Target Milestone|---                         |12.0

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
I see that the :9 and :19 loops (maxv_f32 and minv_f32) use epilogue
vectorization:

/home/rguenther/src/trunk/gcc/testsuite/gcc.target/aarch64/vect-fmaxv-fminv.x:9:13:
optimized: loop vectorized using 16 byte vectors
/home/rguenther/src/trunk/gcc/testsuite/gcc.target/aarch64/vect-fmaxv-fminv.x:9:13:
optimized: loop vectorized using 8 byte vectors
/home/rguenther/src/trunk/gcc/testsuite/gcc.target/aarch64/vect-fmaxv-fminv.x:19:13:
optimized: loop vectorized using 16 byte vectors
/home/rguenther/src/trunk/gcc/testsuite/gcc.target/aarch64/vect-fmaxv-fminv.x:19:13:
optimized: loop vectorized using 8 byte vectors

and have two different vector sizes.  I have no idea what 'fminnmv'
or 'fmaxnmv' are but the vectorizer behaves as intended here.  Somebody
familiar with aarch64 needs to look.  A cc1 cross produces

maxv_f32:
.LFB0:
        .cfi_startproc
        ldr     q1, [x0, 4]
        ld1r    {v3.4s}, [x0]
        ldr     d2, [x0, 20]
        ldr     s0, [x0, 28]
        fmaxnm  v1.4s, v1.4s, v3.4s
        dup     d3, v1.d[1]
        fmaxnm  v1.2s, v1.2s, v3.2s
        fmaxnm  v1.2s, v1.2s, v2.2s
        fmaxnmp s1, v1.2s
        fmaxnm  s0, s0, s1
        ret

and

minv_f32:
.LFB1:
        .cfi_startproc
        ldr     q3, [x0, 4]
        ld1r    {v0.4s}, [x0]
        ldr     q2, [x0, 20]
        fminnm  v3.4s, v3.4s, v0.4s
        ldr     d5, [x0, 52]
        ldr     q1, [x0, 36]
        ldr     s4, [x0, 60]
        fminnm  v2.4s, v2.4s, v3.4s
        fminnm  v1.4s, v1.4s, v2.4s
        dup     d0, v1.d[1]
        fminnm  v0.2s, v1.2s, v0.2s
        fminnm  v0.2s, v0.2s, v5.2s
        fminnmp s0, v0.2s
        fminnm  s0, s4, s0
        ret

not sure what is "wrong" here.  I'd say it's a testsuite or target (costing)
issue.  None of which I can really resolve.

[Bug testsuite/101506] [12 Regression] gcc.target/aarch64/vect-fmaxv-fminv-compile.c fail after gcc-12-2292-g1dd3f2109585

[mkuvyrkov at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rsandifo at gcc dot gnu.org

--- Comment #3 from Maxim Kuvyrkov <mkuvyrkov at gcc dot gnu.org> ---
Richard S., could you investigate, please?  You've added the testcase in 2018
and it hasn't been touched since.

[Bug testsuite/101506] [12 Regression] gcc.target/aarch64/vect-fmaxv-fminv-compile.c fail after gcc-12-2292-g1dd3f2109585

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-07-19
             Status|UNCONFIRMED                 |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rsandifo at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #4 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
(In reply to Maxim Kuvyrkov from comment #3)
> Richard S., could you investigate, please?  You've added the testcase in
> 2018 and it hasn't been touched since.
Well, it goes back to g:77c4ae242f8074a7c7ea4cc8d3793fd899786e1e
(i.e. the initial commit of the aarch64 port).  All we did in 2018
was restrict it to non-SVE targets.

But sure, I'll take it.

[Bug testsuite/101506] [12 Regression] gcc.target/aarch64/vect-fmaxv-fminv-compile.c fail after gcc-12-2292-g1dd3f2109585

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Sandiford <rsandifo@gcc.gnu.org>:

https://gcc.gnu.org/g:1ef9b135793a528c05c4a3e22649744955aa2dfb

commit r12-2414-g1ef9b135793a528c05c4a3e22649744955aa2dfb
Author: Richard Sandiford <richard.sandiford@arm.com>
Date:   Tue Jul 20 15:42:02 2021 +0100

    aarch64: Tweak old vect-* tests to avoid new FAILs

    I'm not sure what these test were originally designed to test.
    vaddv and vmaxv seem to be testing for vectorisation, with associated
    scan-assembler tests.  But they use arm_neon.h functions to test
    the results, which would presumably also trip many of the scans.
    That was probably what the split into vect-fmax-fmin.c and
    vect-fmaxv-fminv-compile.c was supposed to avoid.

    Anyway, the tests started failing after the recent change to allow
    staged reductions for epilogue loops.  And epilogues came into play
    because the reduction loops iterate LANES-1 rather than LANES times.
    (vmaxv was trying to iterate LANES times, but the gimple optimisers
    outsmarted it.  The other two explicitly had a count of LANES-1.)

    Just suppressing epilogues causes other issues for vaddv and vmaxv.
    The easiest fix therefore seemed to be to use an asm to hide the
    initial value of the vmaxv loop (so that it really does iterate
    LANES times) and then make the others match that style.

    gcc/testsuite/
            PR testsuite/101506
            * gcc.target/aarch64/vect-vmaxv.c: Use an asm to hide the
            true initial value of the reduction from the vectorizer.
            * gcc.target/aarch64/vect-vaddv.c: Likewise.  Make the vector
            loop operate on exactly LANES (rather than LANES-1) iterations.
            * gcc.target/aarch64/vect-fmaxv-fminv.x: Likewise.

[Bug testsuite/101506] [12 Regression] gcc.target/aarch64/vect-fmaxv-fminv-compile.c fail after gcc-12-2292-g1dd3f2109585

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:

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

--- Comment #6 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
Fixed.