From 1fdf74c7c9cf637453783669ae0b5f6ff6af3b19 Mon Sep 17 00:00:00 2001 From: Jeff Law Date: Tue, 11 Oct 2016 15:41:51 -0600 Subject: [PATCH] re PR tree-optimization/77424 (Identical statements in if-else branches) PR tree-optimization/77424 * tree-ssa-threadupdate.c (thread_through_all_blocks): Remove dead conditionals. Assert that all e->aux fields are NULL. From-SVN: r241009 --- gcc/ChangeLog | 6 ++++++ gcc/tree-ssa-threadupdate.c | 52 ++++++--------------------------------------- 2 files changed, 12 insertions(+), 46 deletions(-) diff --git a/gcc/ChangeLog b/gcc/ChangeLog index d555c2e..e7b5b0b 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,9 @@ +2016-10-11 Jeff Law + + PR tree-optimization/77424 + * tree-ssa-threadupdate.c (thread_through_all_blocks): Remove + dead conditionals. Assert that all e->aux fields are NULL. + 2016-10-11 David Malcolm * print-rtl.c (print_rtx): Rename "i" to "idx". Split out the diff --git a/gcc/tree-ssa-threadupdate.c b/gcc/tree-ssa-threadupdate.c index 66d919c..325cb0b 100644 --- a/gcc/tree-ssa-threadupdate.c +++ b/gcc/tree-ssa-threadupdate.c @@ -2550,55 +2550,15 @@ thread_through_all_blocks (bool may_peel_loop_headers) retval |= thread_through_loop_header (loop, may_peel_loop_headers); } - /* Any jump threading paths that are still attached to edges at this - point must be one of two cases. - - First, we could have a jump threading path which went from outside - a loop to inside a loop that was ignored because a prior jump thread - across a backedge was realized (which indirectly causes the loop - above to ignore the latter thread). We can detect these because the - loop structures will be different and we do not currently try to - optimize this case. - - Second, we could be threading across a backedge to a point within the - same loop. This occurrs for the FSA/FSM optimization and we would - like to optimize it. However, we have to be very careful as this - may completely scramble the loop structures, with the result being - irreducible loops causing us to throw away our loop structure. - - As a compromise for the latter case, if the thread path ends in - a block where the last statement is a multiway branch, then go - ahead and thread it, else ignore it. */ + /* All jump threading paths should have been resolved at this + point. Verify that is the case. */ basic_block bb; - edge e; FOR_EACH_BB_FN (bb, cfun) { - /* If we do end up threading here, we can remove elements from - BB->preds. Thus we can not use the FOR_EACH_EDGE iterator. */ - for (edge_iterator ei = ei_start (bb->preds); - (e = ei_safe_edge (ei));) - if (e->aux) - { - vec *path = THREAD_PATH (e); - - /* Case 1, threading from outside to inside the loop - after we'd already threaded through the header. */ - if ((*path)[0]->e->dest->loop_father - != path->last ()->e->src->loop_father) - { - delete_jump_thread_path (path); - e->aux = NULL; - ei_next (&ei); - } - else - { - delete_jump_thread_path (path); - e->aux = NULL; - ei_next (&ei); - } - } - else - ei_next (&ei); + edge_iterator ei; + edge e; + FOR_EACH_EDGE (e, ei, bb->preds) + gcc_assert (e->aux == NULL); } statistics_counter_event (cfun, "Jumps threaded", -- 2.7.4