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?
