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

--- Comment #22 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
The most suspicious thing I see in r224221 is following the gap adjustment:

  vect__39.29_261 = REALIGN_LOAD <vect__39.26_282, vect__39.28_264,
vect__39.18_18>;
  vectp_s.20_260 = vectp_s.20_278 + 18446744073709551560;
  vect__39.30_247 = VEC_PERM_EXPR <vect__39.23_1, vect__39.25_297, { 0, 0, 0, 0
}>;
  vect__39.31_246 = VEC_PERM_EXPR <vect__39.23_1, vect__39.25_297, { 0, 0, 0, 0
}>;
  vect__39.32_243 = VEC_PERM_EXPR <vect__39.23_1, vect__39.25_297, { 0, 0, 0, 0
}>;
  vect__39.33_242 = VEC_PERM_EXPR <vect__39.23_1, vect__39.25_297, { 0, 0, 0, 0
}>;
  _39 = *_38[1];
  vect__40.34_229 = VEC_PACK_TRUNC_EXPR <vect__39.30_247, vect__39.31_246>;
  vect__40.34_228 = VEC_PACK_TRUNC_EXPR <vect__39.32_243, vect__39.33_242>;
  _40 = (short int) _39;

Instead of interleaving results from the two vectors, this is splatting the
first element of one of them.  Compare the code from r224220:

  vect__39.61_161 = REALIGN_LOAD <vect__39.58_251, vect__39.60_179,
vect__39.50_259>;
  vect_perm_even_143 = VEC_PERM_EXPR <vect__39.59_233, vect__39.61_161, { 0, 2,
4, 6 }>;
  vect_perm_odd_125 = VEC_PERM_EXPR <vect__39.59_233, vect__39.61_161, { 1, 3,
5, 7 }>;
  _39 = *_38[1];
  vect__40.62_107 = VEC_PACK_TRUNC_EXPR <vect_perm_even_43,
vect_perm_even_143>;
  _40 = (short int) _39;

I walked through the code enough to see that SLP_TREE_LOAD_PERMUTATION for the
SLP tree was just zeros, presumably uninitialized, when read in
tree-vect-slp.c:vect_transform_slp_perm_load.  But I don't know enough about
this code to go further with this tonight.

Reply via email to