https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113994
--- Comment #6 from Stefan Schulze Frielinghaus <stefansf at linux dot ibm.com>
---
Looks like wrong liveness information. The problem is that df_analyze_loop
only considers basic blocks which strictly belong to a loop which is not
enough. During loop2_doloop basic block 9 (previously 8) embodies the CC
consumer jump_insn 42 and is not part of the loop and therefore does not
contribute to the liveness analysis. A quick and dirty experiment by forcing a
merge with BB 9
diff --git a/gcc/df-core.cc b/gcc/df-core.cc
index f0eb4c93957..79f37e22ec1 100644
--- a/gcc/df-core.cc
+++ b/gcc/df-core.cc
@@ -957,9 +957,11 @@ df_worklist_propagate_backward (struct dataflow *dataflow,
if (EDGE_COUNT (bb->succs) > 0)
FOR_EACH_EDGE (e, ei, bb->succs)
{
- if (bbindex_to_postorder[e->dest->index] < last_change_age.length ()
+ if ((bbindex_to_postorder[e->dest->index] < last_change_age.length ()
&& age <= last_change_age[bbindex_to_postorder[e->dest->index]]
&& bitmap_bit_p (considered, e->dest->index))
+ || (strcmp ("loop2_doloop", current_pass->name) == 0
+ && e->src->index == 6 && e->dest->index == 9))
changed |= dataflow->problem->con_fun_n (e);
}
else if (dataflow->problem->con_fun_0)
shows that, now, CC is live at BB 6 and therefore doloop performs no
transformation due to
bool fail = bitmap_intersect_p (df_get_live_out (loop_end), modified);
BITMAP_FREE (modified);
if (fail)
{
if (dump_file)
fprintf (dump_file, "Doloop: doloop pattern clobbers live out\n");
return false;
}
In a first try I enlarged the set of basic blocks for which df_analyze_loop is
run to also include basic blocks which have a direct edge originating from a
basic block of a loop. Of course, this solves this problem. However, in
general this may not be enough. I'm wondering what the IL allows. Is it
possible to have a graph containing not only outgoing edges of a loop but also
ingoing? If so I think we would need to compute the set of basic blocks which
are reachable from within the loop. Any thoughts?
