On 02/25/2016 03:00 AM, Richard Biener wrote:
+ /* Look at BB's successors, if any are marked as BB_IRREDUCIBLE_LOOP,
then
+ removing BB (and its outgoing edges) may make the loop a natural
+ loop. In which case we need to schedule loop fixups. */
+ if (current_loops)
+ for (edge_iterator ei = ei_start (bb->succs); !ei_end_p (ei); ei_next
(&ei))
+ if (ei_edge (ei)->dest->flags & BB_IRREDUCIBLE_LOOP)
+ loops_state_set (LOOPS_NEED_FIXUP);
So I fail to see how only successor edges are relevant. Isn't the important
case to catch whether we remove an edge marked EDGE_IRREDUCIBLE_LOOP?
Even if the BB persists we might have exposed a new loop here.
Yea, let me give that a spin.
Note that it is not safe to look at {BB,EDGE}_IRREDUCIBLE_LOOP if the loop
state does not have LOOPS_HAVE_MARKED_IRREDUCIBLE_REGIONS set
(the flags may be stale or missing). So it might be that we can't rely on
non-loop passes modifying the CFG to handle this optimistically.
I was concerned about this as well. The problem case would be if we
have an irreducible loop with nodes not marked. In that case we could
fail to ask for loop fixups leading to failure again. The other cases
shouldn't cause failures, but can cause us to spend time fixing up loops
which perhaps we didn't need to.
Anyway, I'll have a closer look at that too.
Jeff
