https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105219
--- Comment #10 from Tamar Christina <tnfchris at gcc dot gnu.org> --- nb_iterations_upper_bound is indeed set incorrectly and tracked to this commit, commit 7ed1cd9665d8ca0fa07b2483e604c25e704584af Author: Andre Vieira <andre.simoesdiasvie...@arm.com> Date: Thu Jun 3 13:55:24 2021 +0100 vect: Use main loop's thresholds and VF to narrow upper_bound of epilogue This patch uses the knowledge of the conditions to enter an epilogue loop to help come up with a potentially more restricive upper bound. gcc/ChangeLog: * tree-vect-loop.c (vect_transform_loop): Use main loop's various' thresholds to narrow the upper bound on epilogue iterations. gcc/testsuite/ChangeLog: * gcc.target/aarch64/sve/part_vect_single_iter_epilog.c: New test. I don't quite understand when comparing the two bounds there's a -1 in the min comparison. And indeed: diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc index 5c7b163f01c..19235ea79fe 100644 --- a/gcc/tree-vect-loop.cc +++ b/gcc/tree-vect-loop.cc @@ -9971,7 +9971,7 @@ vect_transform_loop (loop_vec_info loop_vinfo, gimple *loop_vectorized_call) LOOP_VINFO_VECT_FACTOR (loop_vinfo), &bound)) loop->nb_iterations_upper_bound - = wi::umin ((widest_int) (bound - 1), + = wi::umin ((widest_int)bound, loop->nb_iterations_upper_bound); } } fixes it. It looks to me that when comparing the bounds of the main loop and epilogue you shouldn't subtract 1 again. But need to ask why this is there.