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]

[patch] tree-ssa-ccp.c: Clean up ccp_fold.


Hi,

Attached is a patch to clean up ccp_fold.

Without this patch, ccp_fold processes binary expressions like so

  tree rhs = get_rhs (stmt);
  retval = fold_binary (code, TREE_TYPE (rhs), op0, op1);
  if (retval && ! is_gimple_min_invariant (retval))
    return NULL;
  if (retval)
    return fold_convert (TREE_TYPE (rhs), retval);
  return rhs;

The sole caller of ccp_fold basically has

  simplified = ccp_fold (stmt);
  if (simplified && is_gimple_min_invariant (simplified))
    :
    :

It turns out that we have several redundant things going on.  We have
three cases to consider.

fold_binary returns NULL_TREE
-----------------------------

In this case, we return rhs, which is nonnull for a binary expression.
Then the caller of ccp_fold will call is_gimple_min_invariant just to
get "false" returned, which is rather silly.  If we returned NULL_TREE
right away, evaluate_stmt wouldn't have to call
is_gimple_min_invariant.

fold_binary returns a gimple min invariant
------------------------------------------

In this case, we call is_gimple_min_invariant and then call
fold_convert.  However, the call to fold_convert is useless because
fold_binary is supposed to produce a tree node of the right type.
Once evaluate_stmt receives the return value, it will call
is_gimple_min_invariant again.

fold_binary returns nonnull but not a gimple min invariant
----------------------------------------------------------

In this case, we return NULL_TREE after receiving "false" from
is_gimple_min_invariant.

Notice that the first and second cases are particularly long winded.
If we simply return the result of fold_binary directly, the caller,
evaluate_stmt, will take care of checking if the folded expression
satisfies is_gimple_min_invariant.

The same story applies to the unary case.

Tested on i686-pc-linux-gnu.  OK to apply?

Kazu Hirata

2005-05-29  Kazu Hirata  <kazu@cs.umass.edu>

	* tree-ssa-ccp.c (ccp_fold): Return immediately after calling
	fold_unary and fold_binary.

Index: tree-ssa-ccp.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree-ssa-ccp.c,v
retrieving revision 2.74
diff -u -d -p -r2.74 tree-ssa-ccp.c
--- tree-ssa-ccp.c	28 May 2005 21:03:53 -0000	2.74
+++ tree-ssa-ccp.c	28 May 2005 21:40:50 -0000
@@ -849,12 +849,7 @@ ccp_fold (tree stmt)
 	    op0 = get_value (op0, true)->value;
 	}
 
-      retval = fold_unary (code, TREE_TYPE (rhs), op0);
-
-      /* If we folded, but did not create an invariant, then we can not
-	 use this expression.  */
-      if (retval && ! is_gimple_min_invariant (retval))
-	return NULL;
+      return fold_unary (code, TREE_TYPE (rhs), op0);
     }
 
   /* Binary and comparison operators.  We know one or both of the
@@ -885,12 +880,7 @@ ccp_fold (tree stmt)
 	    op1 = val->value;
 	}
 
-      retval = fold_binary (code, TREE_TYPE (rhs), op0, op1);
-
-      /* If we folded, but did not create an invariant, then we can not
-	 use this expression.  */
-      if (retval && ! is_gimple_min_invariant (retval))
-	return NULL;
+      return fold_binary (code, TREE_TYPE (rhs), op0, op1);
     }
 
   /* We may be able to fold away calls to builtin functions if their


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