https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106751
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hubicka at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I'm afraid I don't know much about the RTL lim, but
1840 reorder_insns (inv->insn, inv->insn, BB_END (preheader));
with no check whether it is actually ok to append the statement at the end of
the preheader bb (at least no check that I can find) sounds wrong to me and I'm
just confused why it doesn't break stuff much more often.
>From what I can see, loop-invariant.cc pass happens in between loop2_init and
loop2_done passes where the former calls loop_optimizer_init (LOOPS_NORMAL |
LOOPS_HAVE_RECORDED_EXITS);
which should ensure that loops have preheaders, but doesn't actually ask for
LOOPS_HAVE_FALLTHRU_PREHEADERS.
If the latter was on, then create_preheader would force splitting of the edge:
/* If we want fallthru preheaders, also create forwarder block when
preheader ends with a jump or has predecessors from loop. */
else if ((flags & CP_FALLTHRU_PREHEADERS)
&& (JUMP_P (BB_END (single_entry->src))
|| has_preds_from_loop (single_entry->src, loop)))
need_forwarder_block = true;
So, should loop-invariant.cc split_edge the preheader edge if preheader block
ends with JUMP_P, or shall we somehow arrange for
LOOPS_HAVE_FALLTHRU_PREHEADERS?
