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]

Re: [PATCH] reorganize simplify_const_relational_operation


2007-09-04  Paolo Bonzini  <bonzini@gnu.org>

	* cse.c (fold_rtx): Don't look for an IOR equivalent of
	folded_arg0 if we found a constant equivalent.	Remove
	transformations done in simplify-rtx.c for "op0 RELOP op0".
	* simplify-rtx.c (simplify_const_relational_operation): Improve
	bounds-checking optimizations.	Optimize comparing an IOR with zero.
	Simplify op0 RELOP op0 for floating-point arguments too when
	appropriate.

There are TABs instead of double spaces.  Same in the original ChangeLog.

And the patches are riddled with formatting problems related to TABs too.


@@ -3988,8 +3988,14 @@
     return const0_rtx;
 
   /* For modes without NaNs, if the two operands are equal, we know the
-     result except if they have side-effects.  */
-  if (! HONOR_NANS (GET_MODE (trueop0))
+     result except if they have side-effects.  Even with NaNs we know
+     the results of unordered comparisons and, if signaling NaNs are
+     irrelevant, also the result of LT/GT.  */
+  if ((! HONOR_NANS (GET_MODE (trueop0))
+       || code == UNEQ || code == UNLE || code == UNGE || code == LTGT
+       || code == LT || code == GT)
+      && (! HONOR_SNANS (GET_MODE (trueop0))
+          || (code != LT && code != GT))
       && rtx_equal_p (trueop0, trueop1)
       && ! side_effects_p (trueop0))
     return comparison_result (code, CR_EQ);

'result' without 's'.  The comment doesn't cover LTGT.  I think that

  if ((! HONOR_NANS (GET_MODE (trueop0))
       || code == UNEQ || code == UNLE || code == UNGE || code == LTGT
       || ((code == LT || code == GT) && ! HONOR_SNANS (GET_MODE (trueop0)))

would be clearer.


+	  /* INTVAL/UINTVAL is the same for mmin (it is 0 for unsigned).  */

Slightly incorrect, (UINTVAL(mmin)>>b) != (INTVAL(mmin)>>b) for signed mmin.

+	  mmin = INTVAL (mmin_rtx) >> (sign_copies - 1);
+	  if (sign)
+	    mmax = INTVAL (mmax_rtx) >> (sign_copies - 1);
+	  else
+	    mmax = UINTVAL (mmax_rtx) >> (sign_copies - 1);

Can't we always use UINTVAL for mmax_rtx?

	  /* INTVAL/UINTVAL are equivalent for unsigned mmin.  */
	  mmin = INTVAL (mmin_rtx) >> (sign_copies - 1);
	  /* UINTVAL/INTVAL are equivalent for signed mmax.  */
          mmax = UINTVAL (mmax_rtx) >> (sign_copies - 1);


+      /* See if the first operand is an IOR with a constant.  If so, we
+	 may be able to determine the result of this comparison.  */
+      if (GET_CODE (op0) == IOR)
+        {
+	  rtx inner_const = avoid_constant_pool_reference (XEXP (op0, 1));
+	  if (GET_CODE (inner_const) == CONST_INT)
+	    {

I presume that we can be sure that inner_const is not zero?


Otherwise looks OK to me.

-- 
Eric Botcazou


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