> -----Original Message----- > From: Richard Biener <[email protected]> > Sent: 11 November 2025 12:59 > To: Tamar Christina <[email protected]> > Cc: Victor Do Nascimento <[email protected]>; gcc- > [email protected] > Subject: RE: [PATCH 08/13] vect: Reclassify early break fold left reductions > as > simple reductions > > 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.
You mean like this? https://godbolt.org/z/4jbKx7j5a At first glance that looks correct to me, the early exits use ret_12 and the main exit uses ret_6. So that's handled correctly. Thanks, Tamar > > 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)
