From: Jeff Law <law@redhat.com>
Date: Tue, 11 Oct 2016 21:41:51 +0000 (-0600)
Subject: re PR tree-optimization/77424 (Identical statements in if-else branches)
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=1fdf74c7c9cf637453783669ae0b5f6ff6af3b19;p=gcc.git

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
---

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index d555c2e768b..e7b5b0bbaa8 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2016-10-11  Jeff Law  <law@redhat.com>
+
+	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  <dmalcolm@redhat.com>
 
 	* 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 66d919c95ce..325cb0be8fc 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<jump_thread_edge *> *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",