On Thu, Jul 31, 2025 at 2:56 PM Tamar Christina <tamar.christ...@arm.com> wrote:
>
> Yeah I did think that as well, however what I observed was that if the main
> loop is unrolled because we set the upper bound on loop itself we end up just
> fully unrolling.
>
> And no matter how high I made the VF it would still fully unroll the epilogue
> so it still wouldn't iterate.
You'd probably need to up the unrolling so the epilogue can iterate >
16 times to hit the
param limit of the unroller (well, it should completely peel then, with jumps).
Richard.
> Then of course with a vla epilogue we skip it again.
>
> Cheers,
> Tamar
> ________________________________
> From: Richard Biener <richard.guent...@gmail.com>
> Sent: Thursday, July 31, 2025 1:30 PM
> To: Tamar Christina <tamar.christ...@arm.com>
> Cc: gcc-patches@gcc.gnu.org <gcc-patches@gcc.gnu.org>; nd <n...@arm.com>
> Subject: Re: [PATCH][vect] Don't set bogus bounds on epilogues [PR120805]
>
> On Thu, Jul 31, 2025 at 2:10 PM Tamar Christina <tamar.christ...@arm.com>
> wrote:
> >
> > Hi All,
> >
> > The testcases in the PR are failing due to the code trying to set a vector
> > range
> > on an epilogue.
> >
> > However on epilogues the range doesn't make sense. In particular we are
> > setting
> > ranged to help niters analysis. But the epilogue doesn't iterate.
> >
> > Secondly the bounds variable hasn't been adjusted to vector iterations:
> >
> > In the epilogue this is calculated as
> >
> > <bb 13> [local count: 81467476]:
> > # i_127 = PHI <tmp.7_131(10), 0(5)>
> > # _132 = PHI <_133(10), 0(5)>
> > _181 = (unsigned int) n_41(D);
> > bnd.31_180 = _181 - _132;
> >
> > where
> >
> > _133 = niters_vector_mult_vf.6_130;
> >
> > but _132 is a phi node, and if coming from the vector loop skip edge
> > _181 will be <1, VF>.
> >
> > But this is a range VRP or Ranger can easily report due to the guard on the
> > skip_vector loop.
> >
> > Previously, non-const VF would skip this code entirely due to the
> > .is_constant()
> > check.
> >
> > Non-partial vector loop would also skip it because the bounds would fold to
> > a
> > constant. so it doesn't enter the !gimple_value check.
> >
> > When support for partial vector ranges was added, this accidentally enabled
> > ranges on partial vector epilogues.
> >
> > This patch now makes it explicit that ranges shouldn't be set for
> > epilogues, as
> > they don't seem to be useful anyway.
> >
> > Bootstrapped Regtested on aarch64-none-linux-gnu,
> > arm-none-linux-gnueabihf, x86_64-pc-linux-gnu
> > -m32, -m64 and no issues.
> >
> > Also bootstrapped and Regtested powerpc64-unknown-linux-gnu
> > and failing tests now pass.
> >
> > Ok for master?
>
> OK. Btw, the epilogue could iterate if the target requested unrolling on
> the main vector loop.
>
> Richard.
>
> > Thanks,
> > Tamar
> >
> > gcc/ChangeLog:
> >
> > PR tree-optimization/120805
> > * tree-vect-loop-manip.cc (vect_gen_vector_loop_niters): Skip
> > setting
> > bounds on epilogues.
> >
> > ---
> > diff --git a/gcc/tree-vect-loop-manip.cc b/gcc/tree-vect-loop-manip.cc
> > index
> > 2d01a4b0ed1c8431510ad5e6e2175dbe89371618..c81aff76efa59a2424162b564010d44908f2b778
> > 100644
> > --- a/gcc/tree-vect-loop-manip.cc
> > +++ b/gcc/tree-vect-loop-manip.cc
> > @@ -2857,7 +2857,7 @@ vect_gen_vector_loop_niters (loop_vec_info
> > loop_vinfo, tree niters,
> > we set range information to make niters analyzer's life easier.
> > Note the number of latch iteration value can be TYPE_MAX_VALUE so
> > we have to represent the vector niter TYPE_MAX_VALUE + 1 / vf. */
> > - if (stmts != NULL && const_vf > 0)
> > + if (stmts != NULL && const_vf > 0 && !LOOP_VINFO_EPILOGUE_P
> > (loop_vinfo))
> > {
> > if (niters_no_overflow
> > && LOOP_VINFO_USING_PARTIAL_VECTORS_P (loop_vinfo))
> >
> >
> > --
