[Bug target/110740] New: [14 regression] gcc.target/powerpc/p9-vec-length-epil-1.c

[Bug target/110740] New: [14 regression] gcc.target/powerpc/p9-vec-length-epil-1.c

[seurer at gcc dot gnu.org]

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

            Bug ID: 110740
           Summary: [14 regression]
                    gcc.target/powerpc/p9-vec-length-epil-1.c
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:0682a32c026f1e246eb07bb8066abca4636f01d8, r14-2281-g0682a32c026f1e

These are instruction count tests which may just need count adjustments.

make  -k check-gcc
RUNTESTFLAGS="powerpc.exp=gcc.target/powerpc/p9-vec-length-epil-1.c"
FAIL: gcc.target/powerpc/p9-vec-length-epil-1.c scan-assembler-times \\mlxvl\\M
14
FAIL: gcc.target/powerpc/p9-vec-length-epil-1.c scan-assembler-times
\\mstxvl\\M 7
# of expected passes            3
# of unexpected failures        2


commit 0682a32c026f1e246eb07bb8066abca4636f01d8 (HEAD)
Author: Richard Biener <rguenther@suse.de>
Date:   Mon Jul 3 13:59:33 2023 +0200

    tree-optimization/110310 - move vector epilogue disabling to analysis phase

[Bug target/110740] [14 regression] gcc.target/powerpc/p9-vec-length-epil-1.c

[linkw at gcc dot gnu.org]

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

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
                 CC|                            |linkw at gcc dot gnu.org
   Last reconfirmed|                            |2023-07-20
           Assignee|unassigned at gcc dot gnu.org      |linkw at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Kewen Lin <linkw at gcc dot gnu.org> ---
I'll have a look first, it's likely a test issue.

[Bug target/110740] [14 regression] gcc.target/powerpc/p9-vec-length-epil-1.c

[linkw at gcc dot gnu.org]

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

Kewen Lin <linkw at gcc dot gnu.org> changed:

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

--- Comment #2 from Kewen Lin <linkw at gcc dot gnu.org> ---
Previously function vect_update_epilogue_niters has some code special-casing
the single scalar iteration epilogue:

-static bool
-vect_update_epilogue_niters (loop_vec_info epilogue_vinfo,
-                            unsigned HOST_WIDE_INT const_niters)
-{
-  /* Avoid wrap-around when computing const_niters - 1.  Also reject
-     using an epilogue loop for a single scalar iteration, even if
-     we could in principle implement that using partial vectors.  */
-  unsigned int gap_niters = LOOP_VINFO_PEELING_FOR_GAPS (epilogue_vinfo);
-  if (const_niters <= gap_niters + 1)
-    return false;

It's enabled without any costing consideration before, it sounds quite
reasonable so I think we still want it?

[Bug target/110740] [14 regression] gcc.target/powerpc/p9-vec-length-epil-1.c

[linkw at gcc dot gnu.org]

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

--- Comment #3 from Kewen Lin <linkw at gcc dot gnu.org> ---
Created attachment 55587
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55587&action=edit
trial-patch

This patch can fix the exposed failures on
gcc.target/powerpc/p9-vec-length-epil-{1,8}.c, fully testing it.

[Bug target/110740] [14 regression] gcc.target/powerpc/p9-vec-length-epil-1.c

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hmm, shouldn't this also apply to the main loop?  I suppose we just never get
such a case, but maybe with peeling for gaps we would?  Eventually we'd hope
we never would cost it as profitable.

In any case the patch looks reasonable.

[Bug target/110740] [14 regression] gcc.target/powerpc/p9-vec-length-epil-1.c

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0

[Bug target/110740] [14 regression] gcc.target/powerpc/p9-vec-length-epil-1.c

[linkw at gcc dot gnu.org]

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

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #55587|0                           |1
        is obsolete|                            |

--- Comment #5 from Kewen Lin <linkw at gcc dot gnu.org> ---
Created attachment 55590
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55590&action=edit
patchv2

(In reply to Richard Biener from comment #4)
> Hmm, shouldn't this also apply to the main loop?  

Good question! I think it can. I've updated it to make it not epilogue only.

> I suppose we just never
> get such a case, but maybe with peeling for gaps we would?  Eventually we'd
> hope
> we never would cost it as profitable.

Yeah, it forces this assumption.

[Bug target/110740] [14 regression] gcc.target/powerpc/p9-vec-length-epil-1.c

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:

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

commit r14-2736-gd07504725973ccdec78929a09dc13e5ebd9472f6
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Mon Jul 24 01:20:30 2023 -0500

    vect: Don't vectorize a single scalar iteration loop [PR110740]

    The function vect_update_epilogue_niters which has been
    removed by r14-2281 has some code taking care of that if
    there is only one scalar iteration left for epilogue then
    we won't try to vectorize it any more.

    Although costing should be able to care about it eventually,
    I think we still want this special casing without costing
    enabled, so this patch is to add it back in function
    vect_analyze_loop_costing, and make it more general for
    both main and epilogue loops as Richi suggested, it can fix
    some exposed failures on Power10:

     - gcc.target/powerpc/p9-vec-length-epil-{1,8}.c
     - gcc.dg/vect/slp-perm-{1,5,6,7}.c

            PR tree-optimization/110740

    gcc/ChangeLog:

            * tree-vect-loop.cc (vect_analyze_loop_costing): Do not vectorize a
            loop with a single scalar iteration.

[Bug target/110740] [14 regression] gcc.target/powerpc/p9-vec-length-epil-1.c

[linkw at gcc dot gnu.org]

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

Kewen Lin <linkw at gcc dot gnu.org> changed:

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

--- Comment #7 from Kewen Lin <linkw at gcc dot gnu.org> ---
Should be fixed on trunk.