https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110571
Bug ID: 110571
Summary: vect_determine_partial_vectors_and_peeling required at
vect_do_peeling time
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
When one removes the seemingly no-op call of
vect_determine_partial_vectors_and_peeling in vect_do_peeling you run into
execute FAILs of for example gcc.dg/vect/vect-peel-1-epilogue.c because
that call does
LOOP_VINFO_PEELING_FOR_NITER (loop_vinfo)
= (!LOOP_VINFO_USING_PARTIAL_VECTORS_P (loop_vinfo)
&& need_peeling_or_partial_vectors_p);
which due to vect_need_peeling_or_partial_vectors_p looking at
LOOP_VINFO_INT_NITERS needs to behave differently for the case of
the known number of iterations when falling through from the vector
loop as opposed to when coming around the skip edge.
The caller in vect_do_peeling immediately before adjusts niter:
/* Subtract the number of iterations performed by the vectorized loop
from the number of total iterations. */
tree epilogue_niters = fold_build2 (MINUS_EXPR, TREE_TYPE (niters),
before_loop_niters,
niters);
LOOP_VINFO_NITERS (epilogue_vinfo) = epilogue_niters;
LOOP_VINFO_NITERSM1 (epilogue_vinfo)
= fold_build2 (MINUS_EXPR, TREE_TYPE (epilogue_niters),
epilogue_niters,
build_one_cst (TREE_TYPE (epilogue_niters)));
and then gets the correct answer.
The LOOP_VINFO_NITERS is arguably wrong during most parts of the re-analysis
of the loop as epilogue leading to these kind of issues.
While I think we apply peeling for alignment before going the skip edge way
there is LOOP_VINFO_PEELING_FOR_GAPS which can differ between main and
epilogue. I think we need to know whether we are going to have a skip
edge or not and compute vect_need_peeling_or_partial_vectors_p for the
epilog for both niter kinds.
It's arguably main loop analysis that should compute a (bound) for the
epilogue number of iterations.
