This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

don't stop after sinking the last stmt of a BB


I found this while adding debug annotations, so I don't have a
testcase in which it triggers without debug annotations, but it's
pretty obvious that the current code may miss optimization
opportunities.

The problem is that, after we sink the last stmt in a BB,
bsi_end_p(bsi) becomes true, because we've moved it past the last
stmt.  Since this is the condition we use to tell whether we've
reached the beginning of the BB (we're iterating backwards), we stop
immediately, instead of keeping on the backward iteration.

This patch fixes this, in a not-very-elegant way.  Any better ideas as
to how to make it look nicer?

Ok to install?  bootstrap-tested on x86_64-linux-gnu.

:ADDPATCH ssa-sink:

for  gcc/ChangeLog
from  Alexandre Oliva  <aoliva@redhat.com>

	* tree-ssa-sink.c (sink_code_in_bb): Don't stop sinking after
	sinking the last stmt in a BB.

Index: gcc/tree-ssa-sink.c
===================================================================
--- gcc/tree-ssa-sink.c.orig	2007-08-02 15:50:38.000000000 -0300
+++ gcc/tree-ssa-sink.c	2007-08-02 16:09:17.000000000 -0300
@@ -433,6 +433,7 @@ sink_code_in_bb (basic_block bb)
   block_stmt_iterator bsi;
   edge_iterator ei;
   edge e;
+  bool last = true;
   
   /* If this block doesn't dominate anything, there can't be any place to sink
      the statements to.  */
@@ -454,6 +455,7 @@ sink_code_in_bb (basic_block bb)
 	{
 	  if (!bsi_end_p (bsi))
 	    bsi_prev (&bsi);
+	  last = false;
 	  continue;
 	}      
       if (dump_file)
@@ -472,6 +474,19 @@ sink_code_in_bb (basic_block bb)
 	bsi_move_before (&bsi, &tobsi);
 
       sink_stats.sunk++;
+
+      /* If we've just removed the last statement of the BB, the
+	 bsi_end_p() test below would fail, but bsi_prev() would have
+	 succeeded, and we want it to succeed.  So we keep track of
+	 whether we're at the last statement and pick up the new last
+	 statement.  */
+      if (last)
+	{
+	  bsi = bsi_last (bb);
+	  continue;
+	}
+
+      last = false;
       if (!bsi_end_p (bsi))
 	bsi_prev (&bsi);
       
-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]