https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120805
--- Comment #13 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(In reply to Avinash Jayakar from comment #11)
>
> > I think the code before worked because a non-partial epilogue would have
> > niters_vector
> > be a const (e.g. a gimple value) but the partial iteration loop it's a
> > runtime constant.
> >
> > > So my main doubt here is const_vf, is supposed to be 0 for the epilogue
> > > block right, just like log_vf was null for the epilogue. If so, this is a
> > > simple fix, by assigning a temporary_const_vf, and assigning the actual
> > > value inside the latter mentioned if block. Please do let me know, in this
> > > case I can create a patch.
> >
> > I think we do want a range though for an epilogue if we can, since we know
> > an epilogue
> > iterates at most once, due to how we set the bounds for the loop itself.
> >
> > For the specific case here it can be fixed by
> >
> > diff --git a/gcc/tree-vect-loop-manip.cc b/gcc/tree-vect-loop-manip.cc
> > index 2d01a4b0ed1..c81aff76efa 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))
> >
> > but I think we can provide a range here. The range should be <1,1>. I'll
> > need to
> > double check.
> >
> > So I'll take this one if you don't mind.
>
> Ok, for this particular case this fix would work. But as you said, the range
> should be <1,1> for the epilogue. I added that particular logic here
> + if (niters_no_overflow && !LOOP_VINFO_EPILOGUE_P (loop_vinfo))
> {
> int_range<1> vr (type,
> wi::one (TYPE_PRECISION (type)),
> @@ -2882,6 +2874,14 @@ vect_gen_vector_loop_niters (loop_vec_info
> loop_vinfo, tree niters,
> TYPE_SIGN (type)));
> set_range_info (niters_vector, vr);
> }
> + else if (niters_no_overflow && LOOP_VINFO_EPILOGUE_P (loop_vinfo)) {
> +
> + int_range<1> vr (type,
> + wi::one (TYPE_PRECISION (type)),
> + wi::one (TYPE_PRECISION (type))
> + );
> + set_range_info (niters_vector, vr);
> + }
> Please let me know if this is what you had in mind.
Yeah I think that's because for the epilogue there's no vector loop.
normally niters_vector is the number of vector iterations being performed.
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 n, So no useful range can be set here.
So
iff --git a/gcc/tree-vect-loop-manip.cc b/gcc/tree-vect-loop-manip.cc
index 2d01a4b0ed1..c81aff76efa 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))
is the right fix.
