On Tue, 11 Nov 2025, Tamar Christina wrote: > > -----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?
Just add a FP reduction w/o -ffast-math to any existing early break testcase? You can simply reduce x += 5. or so I think, so no loads necessary. Richard. > Thanks, > Tamar > > > > > [13/13] is still missing for me. > > > > Thanks, > > Richard. > -- Richard Biener <[email protected]> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Jochen Jaser, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
