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').
