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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rsandifo at gcc dot gnu.org

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
So in this case pattern recog destroyed an earlier discovered reduction chain.
From

  # a_lsm.10_28 = PHI <a_lsm.10_11(3), _40(7)>
  _23 = c[b.5_13];
  _24 = _23 != 0;
  _25 = (int) _24;
  _27 = _25 & a_lsm.10_28;
  _35 = b.5_13 + 1;
  _36 = c[_35];
  _37 = _36 != 0;
  _38 = (int) _37;
  _40 = _27 & _38;

we go to

  _23 = c[b.5_13];
  _24 = _23 != 0;
  patt_51 = _24 ? 1 : 0;
  patt_49 = (int) patt_51;   // _25
  patt_48 = (unsigned char) a_lsm.10_28;
  patt_47 = patt_51 & patt_48;
  patt_46 = (int) patt_47;   // _27
  _35 = b.5_13 + 1;
  _36 = c[_35];
  _37 = _36 != 0;
  patt_45 = _37 ? 1 : 0;
  patt_44 = (int) patt_45;  // _38
  patt_43 = patt_47 & patt_45;
  patt_42 = (int) patt_43;  // _40

on the last replacing _40 we fail to identify where the link to the original
_27 continues since we've elided some conversions in the pattern chain.  The
reduction now looks like

  # a_lsm.10_28 = PHI <a_lsm.10_11(3), patt_42(7)>
  _23 = c[b.5_13];
  _24 = _23 != 0;
  patt_51 = _24 ? 1 : 0;
  patt_48 = (unsigned char) a_lsm.10_28;
  patt_47 = patt_51 & patt_48;
  _35 = b.5_13 + 1;
  _36 = c[_35];
  _37 = _36 != 0;
  patt_45 = _37 ? 1 : 0;
  patt_43 = patt_47 & patt_45;
  patt_42 = (int) patt_43;  // _40

which isn't a reduction chain anymore (nor a handled reduction).

Since patterns are not first-class citizens it's not as easly as re-running
reduction analysis to rediscover the cycle.  What we can of course do is
whenever we fail to update STMT_VINFO_REDUC_IDX, try to scrap the reduction
somehow in pattern analysis, or alternatively, when vectorizable_reduction
cannot verify the reduction path, fail reduction vectorization
(I've put in place the assert in pattern recog and reduction vectorization
to see cases we run into such issue).  When we transfer
reduction chain meta to the pattern stmts in
vect_fixup_scalar_cycles_with_patterns that should already handle this case
(but might need to additionally see if the reduc-idx wasn't set).

Testing such a patch.

Reply via email to