https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126998
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Richard Biener from comment #2) > Instead loop splitting is applied (-fno-loop-split resolves the issue). > Loop splitting itself leaves the code in a sorry state: > > _8 = 1; > if (_8 <= 9) > goto <bb 24>; [99.95%] > else > goto <bb 8>; [0.05%] > > so moving invariants there isn't a workaround. So the reason for this is we merge blocks with a degenerate PHI from originally <bb 7> [local count: 118111600]: # a_lsm.16_6 = PHI <_4(6), a_lsm.16_11(5)> # a_lsm_flag.17_13 = PHI <1(6), a_lsm_flag.17_14(5)> # d_lsm.18_12 = PHI <_5(6), 0(5)> _8 = c.7_30 + 1; if (_8 <= 9) and merge_blocks elides a degenerate PHI by using replace_uses_by which creates _8 = 0 + 1; and the folds that, but does not propagate further. So in this case loop splitting exposes a constant propagation opportunity. cddce eventually elides some code but only copyprop resolves the invariant branch. There's similarly degenerate PHIs that are not resolved until copyprop, left over from loop splitting. While the invariant stmts are missed optimizations for the vectorizer it might be not possible to fully resolve all of them - adding a new LIM pass would work, but that can be disabled with flags. So in the end we need to put in defensive measures to avoid ICEing in code that isn't ready to receive unexpected vector types.
