On Tue, 11 Nov 2025, Tamar Christina wrote: > > -----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.
Indeed. So I wonder what goes wrong in the uncounted case - and possibly the peeled case with early break. So I echo Tamar then, Victor, do you have a testcase that shows what goes wrong? Thanks, Richard.
