[Bug tree-optimization/105219] [12 Regression] SVE: Wrong code with -O3 -msve-vector-bits=128 -mtune=thunderx

["avieira at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105219

--- Comment #18 from avieira at gcc dot gnu.org ---
(In reply to Richard Biener from comment #16)
> (In reply to rsandifo@gcc.gnu.org from comment #15)
> > (In reply to Richard Biener from comment #14)
> > > diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
> > > index d7bc34636bd..3b63ab7b669 100644
> > > --- a/gcc/tree-vect-loop.cc
> > > +++ b/gcc/tree-vect-loop.cc
> > > @@ -9977,7 +9981,7 @@ vect_transform_loop (loop_vec_info loop_vinfo, gimple
> > > *loop_vectorized_call)
> > >                             lowest_vf) - 1
> > >            : wi::udiv_floor (loop->nb_iterations_upper_bound +
> > > bias_for_lowest,
> > >                              lowest_vf) - 1);
> > > -      if (main_vinfo)
> > > +      if (main_vinfo && !main_vinfo->peeling_for_alignment)
> > >         {
> > >           unsigned int bound;
> > >           poly_uint64 main_iters
> > It might be better to add the maximum peeling amount to main_iters.
> > Maybe you'd prefer this anyway for GCC 12 though.
> > 
> > I wonder if there's a similar problem for peeling for gaps,
> > in cases where the epilogue doesn't need the same peeling.
> 
> I don't quite understand the code in if (main_vinfo) but the point is
> that for our case main_iters is zero (and so is prologue_iters if that
> would exist).  I'm not sure how the code can be adjusted with that
> given it computes upper bounds and uses min() for the upper bound
> of the epilogue - we'd need to adjust that with a max (2*vf-2,
> old-upper-bound)
> when there's prologue peeling and the short cut exists (I don't actually
> compute that).
> 
> peeling for gaps means we run the epilogue for main VF more iterations,
> but that would just mean the vectorized epilogue executes one more time
> and has peeling for gaps applied as well, so the scalar epilogue runs
> for epilogue VF more iterations.
> 
> I'm not sure what conditions prevent epilogue vectorization but I think
> there were some at least.


I think disabling this for peeling makes sense for now, but just to explain how
the code works.

The perhaps misnamed 'main_iters' represents the maximum number of iterations
left to do after the main loop, either entered or not. The maximum number of
iterations left to do after the main loop the largest of the three:
 - the main loop's VF, in case we enter the main loop there are at most VF-1
iterations left, I see I didn't add a -1 there.
 - LOOP_VINFO_COST_MODEL_THRESHOLD or LOOP_VINFO_VERSIONING_THRESHOLD in case
we don't enter the main loop because we don't have enough iterations to meet
these (but do still have enough for the epilogue).

Our problem is that this didn't take peeling into account, since skipping main
-> skipping peeling and thus really the number of iters we could be left with
after skipping main are actually main_iters + to-peel.

So I think the approach should be to add 'to_peel' to main_iters where
'to_peel' is either:
VF - 1 if PEELING_FOR_GAPS or PEELING_FOR_ALIGNMENT = -1
PEELING_FOR_ALIGNMENT otherwise.

But like I said first, disabling is probably the safest and easiest for gcc 12
and given the niche of this, I'm not even sure it's worth tightening it for gcc
13?