https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111950
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> --- t.c:6:10: note: init: stmt relevant? iftmp.0_9 = _32 ? 1 : iftmp.0_39; t.c:6:10: note: vec_stmt_relevant_p: used out of loop. t.c:6:10: note: vect_is_simple_use: operand _1 != 0, type of def: external t.c:6:10: note: vect_is_simple_use: operand (unsigned int) a.3_23, type of def: external t.c:6:10: note: mark relevant 0, live 1: iftmp.0_9 = _32 ? 1 : iftmp.0_39; t.c:6:10: note: last stmt in pattern. don't mark relevant/live. t.c:6:10: note: vec_stmt_relevant_p: forcing live pattern stmt relevant. t.c:6:10: note: mark relevant 1, live 1: patt_43 = _32 != 0 ? 1 : iftmp.0_39; t.c:6:10: note: init: stmt relevant? c_I_lsm.18_38 = _32 ? 1 : a.3_23; t.c:6:10: note: vec_stmt_relevant_p: used out of loop. t.c:6:10: note: vec_stmt_relevant_p: used out of loop. t.c:6:10: note: vect_is_simple_use: operand _1 != 0, type of def: external t.c:6:10: note: vect_is_simple_use: operand a, type of def: external t.c:6:10: note: mark relevant 0, live 1: c_I_lsm.18_38 = _32 ? 1 : a.3_23; t.c:6:10: note: last stmt in pattern. don't mark relevant/live. t.c:6:10: note: vec_stmt_relevant_p: forcing live pattern stmt relevant. t.c:6:10: note: mark relevant 1, live 1: patt_41 = _32 != 0 ? 1 : a.3_23; t.c:6:10: note: init: stmt relevant? _37 = d.12_13 + 1; t.c:6:10: note: init: stmt relevant? if (_37 != 0) t.c:6:10: note: worklist: examine stmt: patt_41 = _32 != 0 ? 1 : a.3_23; t.c:6:10: note: vect_is_simple_use: operand _1 != 0, type of def: external t.c:6:10: note: vect_is_simple_use: operand 0, type of def: constant t.c:6:10: note: vect_is_simple_use: operand a, type of def: external t.c:6:10: note: worklist: examine stmt: patt_43 = _32 != 0 ? 1 : iftmp.0_39; t.c:6:10: note: vect_is_simple_use: operand _1 != 0, type of def: external t.c:6:10: note: vect_is_simple_use: operand 0, type of def: constant t.c:6:10: note: vect_is_simple_use: operand (unsigned int) a.3_23, type of def: external now, if-conversion managed to CSE the LC PHI node: <bb 19> [local count: 16140304]: # prephitmp_40 = PHI <c_I_lsm.18_38(11), prephitmp_34(23)> # c_I_lsm.18_24 = PHI <c_I_lsm.18_38(11), c_I_lsm.18_33(23)> # iftmp.0_21 = PHI <iftmp.0_9(11), iftmp.0_8(23)> that triggers "interesting" behavior in vectorizable_live_operation which inserts a PHI for the vectorized c_I_lsm.18_38. It will remove the _first_ PHI node using the old scalar (prephitmp_40) and insert a copy for that. It leaves the second around, but will then, running into the remaining USE, replace all uses of c_I_lsm.18_24 with the vectorized result: <bb 32> [local count: 14526274]: # c_I_lsm.18_59 = PHI <c_I_lsm.18_38(11)> # d.12_61 = PHI <_37(11)> # vect_patt_43.28_82 = PHI <vect_patt_43.28_81(11)> # vect_patt_41.29_91 = PHI <vect_patt_41.29_90(11)> _92 = BIT_FIELD_REF <vect_patt_41.29_91, 32, 96>; prephitmp_58 = _92; _83 = BIT_FIELD_REF <vect_patt_43.28_82, 32, 96>; iftmp.0_60 = _83; niters_vector_mult_vf.26_68 = bnd.25_67 << 2; _70 = (int) niters_vector_mult_vf.26_68; tmp.27_69 = d.12_5 + _70; if (niters.24_48 == niters_vector_mult_vf.26_68) this all doesn't make much sense to me ... doing the "obvious" doesn't fix this bug. It seems things are wrong already when the epilog peeling happens where for the merge PHI after the epilog we somehow failed to update the PHI node for c_I_lsm.18_73. Looks like we didn't get rid of 'find_guard_arg' ... and it relies on get_current_def which in turn relies on "copying" that info from the scalar copy to the original loop (the magic in slpeel_duplicate_current_defs_from_edges). That was all fragile in the past, I guess it's now simply broken, at least for the special case we have here.
