[Bug tree-optimization/96451] New: [11 Regression] gcc.dg/pr68766.c ICE since r11-2453

[Bug tree-optimization/96451] New: [11 Regression] gcc.dg/pr68766.c ICE since r11-2453

[jakub at gcc dot gnu.org]

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

            Bug ID: 96451
           Summary: [11 Regression] gcc.dg/pr68766.c ICE since r11-2453
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Since r11-2453-gc89366b12ff4f36253bae125b794cbe687f7e40b the pr68766.c testcase
ICEs on x86_64-linux, with:
./cc1 -quiet -O2 -ftree-vectorize -fdbg-cnt=vect_loop:1 -mavx2 pr68766.c
***dbgcnt: lower limit 1 reached for vect_loop.***
during RTL pass: expand
pr68766.c: In function ‘fn1’:
pr68766.c:12:12: internal compiler error: in maybe_gen_insn, at optabs.c:7316
   12 |       c[g] = b;
      |       ~~~~~^~~
0x10badc9 maybe_gen_insn(insn_code, unsigned int, expand_operand*)
        ../../gcc/optabs.c:7316
0x10bb219 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
        ../../gcc/optabs.c:7360
0x10bb2ad expand_insn(insn_code, unsigned int, expand_operand*)
        ../../gcc/optabs.c:7391
0xeb3cdf expand_partial_store_optab_fn
        ../../gcc/internal-fn.c:2570
0xeb854f expand_MASK_STORE
        ../../gcc/internal-fn.def:138
Seems a scalar MASK_STORE ifn ends up in the IL even when the backend doesn't
have any scalar masked store optabs, only vector ones.

[Bug tree-optimization/96451] [11 Regression] gcc.dg/pr68766.c ICE since r11-2453

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.0
                 CC|                            |linkw at gcc dot gnu.org

[Bug tree-optimization/96451] [11 Regression] gcc.dg/pr68766.c ICE since r11-2453

[linkw at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
           Assignee|unassigned at gcc dot gnu.org      |linkw at gcc dot gnu.org
   Last reconfirmed|                            |2020-08-04
             Status|UNCONFIRMED                 |ASSIGNED

--- Comment #1 from Kewen Lin <linkw at gcc dot gnu.org> ---
Thanks for reporting! I will have a look at it.

[Bug tree-optimization/96451] [11 Regression] gcc.dg/pr68766.c ICE since r11-2453

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
possibly a latent issue since the patch is supposed to be cost-only

[Bug tree-optimization/96451] [11 Regression] gcc.dg/pr68766.c ICE since r11-2453

[linkw at gcc dot gnu.org]

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

--- Comment #3 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #2)
> possibly a latent issue since the patch is supposed to be cost-only

Yes, this case will hit ICE too with -fno-vect-cost-model even without the
culprit commit.

Without that commit, the costing says it's not profitable to vectorize the
epilogue further, while with that we are able to vectorize the epilogue. With
the forced option -fdbg-cnt=vect_loop:1, it only allows us to vectorize one
loop, so it skips the epilogue which has the scalar mask_store statement from
if-cvt and is determined to be vectorized.

I'm not sure what the dbg counter should mean for loop vect. If it's for the
original scalar loop, then the main vectorized loop and the epilogue loop to be
vectorized should be vectorized. The fix could be: 

diff --git a/gcc/tree-vectorizer.c b/gcc/tree-vectorizer.c
index 26a1846..150bdcf 100644
--- a/gcc/tree-vectorizer.c
+++ b/gcc/tree-vectorizer.c
@@ -1066,7 +1066,7 @@ try_vectorize_loop_1 (hash_table<simduid_to_vf>
*&simduid_to_vf_htab,
       return ret;
     }

-  if (!dbg_cnt (vect_loop))
+  if (!LOOP_VINFO_EPILOGUE_P (loop_vinfo) && !dbg_cnt (vect_loop))
     {
       /* Free existing information if loop is analyzed with some
         assumptions.  */

If the dbg counter is for all kinds of loop (main or epilogue), the fix seems
to be: add one interface for dbg counter framework to query the remaining
allowed count, compare the remaining number and the number of epilogue loops in
vect_do_peeling, then remove the exceeding epilogue loops there.

[Bug tree-optimization/96451] [11 Regression] gcc.dg/pr68766.c ICE since r11-2453

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 5 Aug 2020, linkw at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96451
> 
> --- Comment #3 from Kewen Lin <linkw at gcc dot gnu.org> ---
> (In reply to Richard Biener from comment #2)
> > possibly a latent issue since the patch is supposed to be cost-only
> 
> Yes, this case will hit ICE too with -fno-vect-cost-model even without the
> culprit commit.
> 
> Without that commit, the costing says it's not profitable to vectorize the
> epilogue further, while with that we are able to vectorize the epilogue. With
> the forced option -fdbg-cnt=vect_loop:1, it only allows us to vectorize one
> loop, so it skips the epilogue which has the scalar mask_store statement from
> if-cvt and is determined to be vectorized.
> 
> I'm not sure what the dbg counter should mean for loop vect. If it's for the
> original scalar loop, then the main vectorized loop and the epilogue loop to be
> vectorized should be vectorized. The fix could be: 
> 
> diff --git a/gcc/tree-vectorizer.c b/gcc/tree-vectorizer.c
> index 26a1846..150bdcf 100644
> --- a/gcc/tree-vectorizer.c
> +++ b/gcc/tree-vectorizer.c
> @@ -1066,7 +1066,7 @@ try_vectorize_loop_1 (hash_table<simduid_to_vf>
> *&simduid_to_vf_htab,
>        return ret;
>      }
> 
> -  if (!dbg_cnt (vect_loop))
> +  if (!LOOP_VINFO_EPILOGUE_P (loop_vinfo) && !dbg_cnt (vect_loop))
>      {
>        /* Free existing information if loop is analyzed with some
>          assumptions.  */
> 
> If the dbg counter is for all kinds of loop (main or epilogue), the fix seems
> to be: add one interface for dbg counter framework to query the remaining
> allowed count, compare the remaining number and the number of epilogue loops in
> vect_do_peeling, then remove the exceeding epilogue loops there.

I think the above patch is OK and is what was originally intended.

Care to push it to master?

[Bug tree-optimization/96451] [11 Regression] gcc.dg/pr68766.c ICE since r11-2453

[linkw at gcc dot gnu.org]

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

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

Just noticed the dbgcnt supports several intervals, if we want to count
epilogue loop, we probably need to call dbgcnt in vect_do_peeling. One untested
patch attached to show the idea.

[Bug tree-optimization/96451] [11 Regression] gcc.dg/pr68766.c ICE since r11-2453

[linkw at gcc dot gnu.org]

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

--- Comment #6 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #4)
> On Wed, 5 Aug 2020, linkw at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96451
> > 
> > --- Comment #3 from Kewen Lin <linkw at gcc dot gnu.org> ---
> > (In reply to Richard Biener from comment #2)
> > > possibly a latent issue since the patch is supposed to be cost-only
> > 
> > Yes, this case will hit ICE too with -fno-vect-cost-model even without the
> > culprit commit.
> > 
> > Without that commit, the costing says it's not profitable to vectorize the
> > epilogue further, while with that we are able to vectorize the epilogue. With
> > the forced option -fdbg-cnt=vect_loop:1, it only allows us to vectorize one
> > loop, so it skips the epilogue which has the scalar mask_store statement from
> > if-cvt and is determined to be vectorized.
> > 
> > I'm not sure what the dbg counter should mean for loop vect. If it's for the
> > original scalar loop, then the main vectorized loop and the epilogue loop to be
> > vectorized should be vectorized. The fix could be: 
> > 
> > diff --git a/gcc/tree-vectorizer.c b/gcc/tree-vectorizer.c
> > index 26a1846..150bdcf 100644
> > --- a/gcc/tree-vectorizer.c
> > +++ b/gcc/tree-vectorizer.c
> > @@ -1066,7 +1066,7 @@ try_vectorize_loop_1 (hash_table<simduid_to_vf>
> > *&simduid_to_vf_htab,
> >        return ret;
> >      }
> > 
> > -  if (!dbg_cnt (vect_loop))
> > +  if (!LOOP_VINFO_EPILOGUE_P (loop_vinfo) && !dbg_cnt (vect_loop))
> >      {
> >        /* Free existing information if loop is analyzed with some
> >          assumptions.  */
> > 
> > If the dbg counter is for all kinds of loop (main or epilogue), the fix seems
> > to be: add one interface for dbg counter framework to query the remaining
> > allowed count, compare the remaining number and the number of epilogue loops in
> > vect_do_peeling, then remove the exceeding epilogue loops there.
> 
> I think the above patch is OK and is what was originally intended.
> 
> Care to push it to master?

Thanks for the confirmation! I'll proceed with one formal patch.

[Bug tree-optimization/96451] [11 Regression] gcc.dg/pr68766.c ICE since r11-2453

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 5 Aug 2020, linkw at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96451
> 
> --- Comment #5 from Kewen Lin <linkw at gcc dot gnu.org> ---
> Created attachment 49000
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49000&action=edit
> untested patch
> 
> Just noticed the dbgcnt supports several intervals, if we want to count
> epilogue loop, we probably need to call dbgcnt in vect_do_peeling. One untested
> patch attached to show the idea.

We should count original scalar loops, not the loops we generate.

[Bug tree-optimization/96451] [11 Regression] gcc.dg/pr68766.c ICE since r11-2453

[linkw at gcc dot gnu.org]

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

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

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

--- Comment #8 from Kewen Lin <linkw at gcc dot gnu.org> ---
The proposed fix has been committed in
r11-2585-gea858d09571f3f6dcce92d8bfaf077f9d44c6ad6

Sorry that forgot to put the PR No. to the changelog.