On Mon, 10 Nov 2025, Victor Do Nascimento wrote: > From: Victor Do Nascimento > <[email protected]> > > This re-categorization of reductions for uncounted loops involving > reductions leads to the correct calling of > `vect_create_epilog_for_reduction' function. > > gcc/ChangeLog: > > * tree-vect-loop.cc (vectorizable_reduction): Reclassify > uncounted-loop VECT_REDUC_INFO_TYPE as TREE_CODE_REDUCTION. > --- > gcc/tree-vect-loop.cc | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc > index 901903cfbea..3b038169c95 100644 > --- a/gcc/tree-vect-loop.cc > +++ b/gcc/tree-vect-loop.cc > @@ -7426,8 +7426,9 @@ vectorizable_reduction (loop_vec_info loop_vinfo, > "supported.\n"); > return false; > } > - VECT_REDUC_INFO_TYPE (reduc_info) > - = reduction_type = FOLD_LEFT_REDUCTION; > + VECT_REDUC_INFO_TYPE (reduc_info) = reduction_type > + = LOOP_VINFO_NITERS_UNCOUNTED_P (loop_vinfo) ? TREE_CODE_REDUCTION > + : FOLD_LEFT_REDUCTION;
I don't think this is correct. We've arrived here with a needs_fold_left_reduction_p check, if we cannot use a FOLD_LEFT_REDUCTION we have to fail. That said, instead of vect_create_epilog_for_reduction this goes through vectorize_fold_left_reduction which re-uses the original scalar reduction PHI and thus any specific early-break handling would need to go there. I believe that if this is an issue with respect to re-starting then that very same issue is present generally for early break vectorization. [13/13] is still missing for me. Thanks, Richard.
