https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111950
--- Comment #4 from Tamar Christina <tnfchris at gcc dot gnu.org> --- > turning c_I_lsm.18_38 into a fully invariant reduction def which likely isn't supported - we had bugs here in the past with not relevant but live stmts. But if-conversion also performs the (now valid) hoisting, this is maybe why it was triggered by that rev. Ah yeah this is something different from what I just fixed. Indeed, this causes find_guard_arg to no longer find the tie to the original PHI. It's trying to match # c_I_lsm.18_60 = PHI <a.3_23(33), 1(36)> and # c_I_lsm.18_79 = PHI <c_I_lsm.18_60(35)> after it adds the edge. Normally loop invariant values are left in the the guard block for this. In this case we've left # c_I_lsm.18_65 = PHI <c_I_lsm.18_38(11)> Normally instead of # c_I_lsm.18_60 = PHI <a.3_23(33), 1(36)> we'd find c_I_lsm.18_65 here. The value is as you mentioned loop invariant. but since c_I_lsm.18_38 is no longer a PHI node the link was broken. I don't think we can really recover this in the vectorizer can we? Would the proper fix perhaps be to have ifconvert fully convert things? It seems to have missed that # c_I_lsm.18_60 = PHI <a.3_23(33), 1(36)> is just c_I_lsm.18_60 = _58 ? 1 : a.3_23; that would prevent the PHI node confusion