[PATCH] Fix scev tuplification bug (PR tree-optimization/37416)

Jakub Jelinek jakub@redhat.com
Tue Dec 9 22:20:00 GMT 2008


Tuplification resulted in some loops to have unknown number of iterations
computed.  The problem is that follow_ssa_edge_in_rhs before tuplification
handled NOP_EXPR, but as it is GIMPLE_UNARY_RHS, it doesn't handle it

Fixed thusly, bootstrapped/regtested on x86_64-linux and tested that
on the testcase from PR in vect dump symbolic number of iterations is
printed again as in 4.3 and the loop is vectorized.  I'd appreciate some
help with the testcase for this (in which dump to look at, on which arches
to run the test (e.g. if short is as wide as int, I'm not sure if it should
pass, etc.).

Ok for trunk?

2008-12-09  Jakub Jelinek  <jakub@redhat.com>

	PR tree-optimization/37416
	* tree-scalar-evolution.c (follow_ssa_edge_in_rhs): Handle NOP_EXPR.

--- gcc/tree-scalar-evolution.c.jj	2008-11-10 10:28:26.000000000 +0100
+++ gcc/tree-scalar-evolution.c	2008-12-09 21:17:10.000000000 +0100
@@ -1229,6 +1229,18 @@ follow_ssa_edge_in_rhs (struct loop *loo
       return follow_ssa_edge_expr (loop, stmt, gimple_assign_rhs1 (stmt),
 				   halting_phi, evolution_of_loop, limit);
+      if (code == NOP_EXPR)
+	{
+	  /* This assignment is under the form "a_1 = (cast) rhs.  */
+	  t_bool res
+	    = follow_ssa_edge_expr (loop, stmt, gimple_assign_rhs1 (stmt),
+				    halting_phi, evolution_of_loop, limit);
+	  *evolution_of_loop = chrec_convert (type, *evolution_of_loop, stmt);
+	  return res;
+	}
+      /* FALLTHRU */
       return t_false;


More information about the Gcc-patches mailing list