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.
