> -----Original Message----- > From: Richard Biener <[email protected]> > Sent: 11 November 2025 12:16 > To: Victor Do Nascimento <[email protected]> > Cc: [email protected]; Tamar Christina <[email protected]>; > Victor Do Nascimento <[email protected] > 1.compute.internal> > Subject: Re: [PATCH 08/13] vect: Reclassify early break fold left reductions > as > simple reductions > > On Mon, 10 Nov 2025, Victor Do Nascimento wrote: > > > From: Victor Do Nascimento <[email protected] > 1.compute.internal> > > > > 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.
Agree, I think vectorizable_reduction is missing support for reducing from def 0. Note that we mostly normally fail to analyse the reduction so we never get here hence the missing support, so I'm somewhat surprised uncounted loops did. Is there a testcase that shows this? Thanks, Tamar > > [13/13] is still missing for me. > > Thanks, > Richard.
