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.
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))
>
>
> --
