This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/64404] [5 Regression] ICE: in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1464 with --param=sccvn-max-alias-queries-per-access=1


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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ok, this also shows the (known :/) wrong-code issue we have with the same-dr
and mixed SLP / loop vectorization.  The vectorizer is fed

  <bb 3>:
  # d_16 = PHI <d_13(4), 0(2)>
  # ivtmp_15 = PHI <ivtmp_14(4), 1024(2)>
  _4 = X[d_16].l;
  _5 = X[d_16].h;
  _6 = _4 + _5;
  Y[d_16].l = _6;
  Y[d_16].h = _6;
  Z[d_16].l = _4;
  _11 = X[d_16].h;
  Z[d_16].h = _11;
  d_13 = d_16 + 1;
  ivtmp_14 = ivtmp_15 - 1;
  if (ivtmp_14 != 0)
    goto <bb 4>;
  else
    goto <bb 5>;

  <bb 4>:
  goto <bb 3>;

where the Y = X op is SLPed but the Z = X one fails to SLP because of the
CSEd load (thus SLP analysis figures that the store has gaps).  When
trying to loop vectorize the Z = X op (by unrolling the loop once)
we get at the DEF for _11 which unfortunately is already vectorized
with SLP and the vectorized stmt is the one with the load permutation
applied.

We really are not prepared to vectorize this loop!

In fact the second X.h load shouldn't be considered a grouped load, but
nothing "splits" it apart again.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]