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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hmm, I thought I fixed this - we have a NOP_EXPR-only "reduction".

<bb 4> [local count: 477815112]:
# d.2_14 = PHI <_4(9), d.2_13(15)>
# c_b_lsm.6_7 = PHI <_3(9), c_b_lsm.6_12(15)>
f_9 = (int) c_b_lsm.6_7;
_3 = (char) f_9;
_4 = d.2_14 + 1;
if (_4 != 0)
  goto <bb 9>; [89.00%]
else

<bb 9> [local count: 425255450]:
goto <bb 4>; [100.00%]

t.c:7:10: note:   Access function of PHI: c_b_lsm.6_7
t.c:7:10: note:   Analyze phi: c_b_lsm.6_7 = PHI <_3(9), c_b_lsm.6_12(15)>
t.c:7:10: note:   reduction path: _3 f_9 c_b_lsm.6_7
t.c:7:10: note:   reduction: detected reduction
t.c:7:10: note:   Detected reduction.
...
t.c:7:10: note:   vect_recog_cast_forwprop_pattern: detected: _3 = (char) f_9;
t.c:7:10: note:   cast_forwprop pattern recognized: patt_17 = (char)
c_b_lsm.6_7;

that's a missed optimization in the pattern (c_b_lsm.6_7 is already 'char').

Reply via email to