[Bug optimization/14848] New: [tree-ssa] prefer EQ_EXPR and NE_EXPR to ordered comparisons

[Bug optimization/14848] New: [tree-ssa] prefer EQ_EXPR and NE_EXPR to ordered comparisons

[kazu at cs dot umass dot edu]

Consider:

void bar (unsigned int);

void
foo (unsigned int a)
{
  if (a == 0)
    if (a < 1)
      bar (a);
}

void
baz (unsigned int a)
{
  if (a < 1)
    if (a == 0)
      bar (a);
}

I get:

;; Function foo (foo)

foo (a)
{
<bb 0>:
  if (a == 0) goto <L1>; else goto <L2>; <- looks good

<L1>:;
  bar (0) [tail call];                   <- looks good

<L2>:;
  return;

}



;; Function baz (baz)

baz (a)
{
<bb 0>:
  if (a <= 0) goto <L1>; else goto <L2>;  <- a <= 0 looks ugly

<L1>:;
  bar (a) [tail call];                    <- why not bar (0)?

<L2>:;
  return;

}

We may want to prefer EQ_EXPR and NE_EXPR to ordered comparisons
whenever possible.  Among various benefits, EQ_EXPR and NE_EXPR
don't care about signedness.

Equality comparison against 0, in particular, should be no more expensive than
(unsigned) a <= 0 on most, if not all, targets.  In fact, on x86,

	testl	%eax, %eax	# 32	*cmpsi_ccno_1/1	[length = 2] <- Look!
	je	.L5	# 10	*jcc_1	[length = 2]

	cmpl	$0, %eax	# 9	*cmpsi_1_insn/1	[length = 3] <- Look!
	jbe	.L9	# 10	*jcc_1	[length = 2]

-- 
           Summary: [tree-ssa] prefer EQ_EXPR and NE_EXPR to ordered
                    comparisons
           Product: gcc
           Version: tree-ssa
            Status: UNCONFIRMED
          Keywords: pessimizes-code
          Severity: enhancement
          Priority: P2
         Component: optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: kazu at cs dot umass dot edu
                CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14848

[Bug optimization/14848] [tree-ssa] prefer EQ_EXPR and NE_EXPR to ordered comparisons

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-04 17:38 -------
Confirmed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-04-04 17:38:34
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14848

[Bug optimization/14848] [tree-ssa] prefer EQ_EXPR and NE_EXPR to ordered comparisons

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-06 19:18 -------
DOM's jump threading is causing this.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at gcc dot gnu dot org
   Target Milestone|---                         |tree-ssa


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14848

[Bug optimization/14848] [tree-ssa] prefer EQ_EXPR and NE_EXPR to ordered comparisons

[law at gcc dot gnu dot org]

------- Additional Comments From law at gcc dot gnu dot org  2004-04-07 18:25 -------
(In reply to comment #2)
> DOM's jump threading is causing this.
Really?

If you look at the .original dump you'll find that DOM is merely optimizing the
comparisons which are provided by the front-end.  ie, the .original dump looks
like:

;; Function baz (baz)
;; enabled by -tree-original


{
   if (a <= 0u)
      if (a == 0u)
         bar(a);


}

Note carefully the <= in the first conditonal.

All DOM did was realize that the second conditional was subsumed by the first
and eliminate the second conditional.

It could be argued that DOM could clean up the first conditional and that may
be a reasonable thing to do.  However, it could also be argued that the FE
shouldn't have generated such bogus code to begin with.

jeff


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14848

[Bug optimization/14848] [tree-ssa] prefer EQ_EXPR and NE_EXPR to ordered comparisons

[law at redhat dot com]

------- Additional Comments From law at redhat dot com  2004-04-08 22:52 -------
Subject: Re:  [tree-ssa] prefer EQ_EXPR and NE_EXPR to 
 ordered comparisons

In message <20040406191818.15333.qmail@sources.redhat.com>, "pinskia at gcc dot
 gnu dot org" writes:
 >
 >------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-06 1
 >9:18 -------
 >DOM's jump threading is causing this.
As I mentioned in an earlier message, DOM isn't causing this, it's lame
code from the front-end.

Unfortunately, this is yet more lossage related to trying to share code
for folding tests against a type's min/max value between the main folder
and the non-destructive folder used by CCP).  fold_relational_hi_lo
detects the optimization opportunity, but the main folder ignores the
result.  Ugh.

Given the numerous problems we've had trying to share that code and the 
fact that trying to share the code just makes merges harder, I've decide
to no longer try and share code.

This patch fixes the folders so that the front-end doesn't pass down lame
code for this testcase to the ssa optimizers.

Interestingly it also fixes a couple of the execute/loop-blah.c failures
probably because we pass slightly better trees down to the RTL optimizers
and thus avoiding some latent backend bug.

It initially appeared that the patch was causing 12658_thread.cc to 
regress.  However, further testing has shown that 12658_thread.cc appears
to randomly fail -- same binary works sometimes and fails other times.
That behavior is independent of this patch.

	* fold-const.c (fold): Remove attempt to share code which 
	simplifies tests against the highest/lowest value of a
	range between the main folder and the nondestructive folder.

Index: fold-const.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/fold-const.c,v
retrieving revision 1.213.2.84
diff -c -p -r1.213.2.84 fold-const.c
*** fold-const.c	1 Apr 2004 17:33:56 -0000	1.213.2.84
--- fold-const.c	8 Apr 2004 22:40:02 -0000
*************** fold (tree expr)
*** 7428,7444 ****
  	    }
  	}
  
!       t1 = fold_relational_hi_lo (&code, type, &arg0, &arg1);
  
!       /* If fold_relational_hi_lo returns non-null, then it folded the
!          relational into a constant.  So just return it.  Otherwise,
! 	 rebuild the expression since the underlying components may have
! 	 changed.  */
!       if (t1)
! 	return t1;
!       else if (code != TREE_CODE (t)
! 	       || TREE_OPERAND (t, 0) != arg0 || TREE_OPERAND (t, 1) != arg1)
! 	tem = build (code, type, arg0, convert (TREE_TYPE (arg0), arg1));
  
        /* If this is an EQ or NE comparison of a constant with a PLUS_EXPR or
  	 a MINUS_EXPR of a constant, we can convert it into a comparison with
--- 7428,7562 ----
  	    }
  	}
  
!       /* Comparisons with the highest or lowest possible integer of
! 	 the specified size will have known values. 
  
! 	 This is quite similar to fold_relational_hi_lo; however, my
! 	 attempts to share the code have been nothing but trouble.
! 	 I give up for now.  */
!       {
! 	int width = GET_MODE_BITSIZE (TYPE_MODE (TREE_TYPE (arg1)));
! 
! 	if (TREE_CODE (arg1) == INTEGER_CST
! 	    && ! TREE_CONSTANT_OVERFLOW (arg1)
! 	    && width <= HOST_BITS_PER_WIDE_INT
! 	    && (INTEGRAL_TYPE_P (TREE_TYPE (arg1))
! 		|| POINTER_TYPE_P (TREE_TYPE (arg1))))
! 	  {
! 	    unsigned HOST_WIDE_INT signed_max;
! 	    unsigned HOST_WIDE_INT max, min;
! 
! 	    signed_max = ((unsigned HOST_WIDE_INT) 1 << (width - 1)) - 1;
! 
! 	    if (TREE_UNSIGNED (TREE_TYPE (arg1)))
! 	      {
! 	        max = ((unsigned HOST_WIDE_INT) 2 << (width - 1)) - 1;
! 		min = 0;
! 	      }
! 	    else
! 	      {
! 	        max = signed_max;
! 		min = ((unsigned HOST_WIDE_INT) -1 << (width - 1));
! 	      }
! 
! 	    if (TREE_INT_CST_HIGH (arg1) == 0
! 		&& TREE_INT_CST_LOW (arg1) == max)
! 	      switch (code)
! 		{
! 		case GT_EXPR:
! 		  return omit_one_operand (type,
! 					   fold_convert (type,
! 							 integer_zero_node),
! 					   arg0);
! 		case GE_EXPR:
! 		  return fold (build (EQ_EXPR, type, arg0, arg1));
! 
! 		case LE_EXPR:
! 		  return omit_one_operand (type,
! 					   fold_convert (type,
! 							 integer_one_node),
! 					   arg0);
! 		case LT_EXPR:
! 		  return fold (build (NE_EXPR, type, arg0, arg1));
! 
! 		/* The GE_EXPR and LT_EXPR cases above are not normally
! 		   reached because of previous transformations.  */
! 
! 		default:
! 		  break;
! 		}
! 	    else if (TREE_INT_CST_HIGH (arg1) == 0
! 		     && TREE_INT_CST_LOW (arg1) == max - 1)
! 	      switch (code)
! 		{
! 		case GT_EXPR:
! 		  arg1 = const_binop (PLUS_EXPR, arg1, integer_one_node, 0);
! 		  return fold (build (EQ_EXPR, type, arg0, arg1));
! 		case LE_EXPR:
! 		  arg1 = const_binop (PLUS_EXPR, arg1, integer_one_node, 0);
! 		  return fold (build (NE_EXPR, type, arg0, arg1));
! 		default:
! 		  break;
! 		}
! 	    else if (TREE_INT_CST_HIGH (arg1) == (min ? -1 : 0)
! 		     && TREE_INT_CST_LOW (arg1) == min)
! 	      switch (code)
! 		{
! 		case LT_EXPR:
! 		  return omit_one_operand (type,
! 					   fold_convert (type,
! 							 integer_zero_node),
! 					   arg0);
! 		case LE_EXPR:
! 		  return fold (build (EQ_EXPR, type, arg0, arg1));
! 
! 		case GE_EXPR:
! 		  return omit_one_operand (type,
! 					   fold_convert (type,
! 							 integer_one_node),
! 					   arg0);
! 		case GT_EXPR:
! 		  return fold (build (NE_EXPR, type, arg0, arg1));
! 
! 		default:
! 		  break;
! 		}
! 	    else if (TREE_INT_CST_HIGH (arg1) == (min ? -1 : 0)
! 		     && TREE_INT_CST_LOW (arg1) == min + 1)
! 	      switch (code)
! 		{
! 		case GE_EXPR:
! 		  arg1 = const_binop (MINUS_EXPR, arg1, integer_one_node, 0);
! 		  return fold (build (NE_EXPR, type, arg0, arg1));
! 		case LT_EXPR:
! 		  arg1 = const_binop (MINUS_EXPR, arg1, integer_one_node, 0);
! 		  return fold (build (EQ_EXPR, type, arg0, arg1));
! 		default:
! 		  break;
! 		}
! 
! 	    else if (!in_gimple_form
! 		     && TREE_INT_CST_HIGH (arg1) == 0
! 		     && TREE_INT_CST_LOW (arg1) == signed_max
! 		     && TREE_UNSIGNED (TREE_TYPE (arg1))
! 		     /* signed_type does not work on pointer types.  */
! 		     && INTEGRAL_TYPE_P (TREE_TYPE (arg1)))
! 	      {
! 		/* The following case also applies to X < signed_max+1
! 		   and X >= signed_max+1 because previous transformations.  */
! 		if (code == LE_EXPR || code == GT_EXPR)
! 		  {
! 		    tree st0, st1;
! 		    st0 = lang_hooks.types.signed_type (TREE_TYPE (arg0));
! 		    st1 = lang_hooks.types.signed_type (TREE_TYPE (arg1));
! 		    return fold
! 		      (build (code == LE_EXPR ? GE_EXPR: LT_EXPR,
! 			      type, fold_convert (st0, arg0),
! 			      fold_convert (st1, integer_zero_node)));
! 		  }
! 	      }
! 	  }
!       }
  
        /* If this is an EQ or NE comparison of a constant with a PLUS_EXPR or
  	 a MINUS_EXPR of a constant, we can convert it into a comparison with












-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14848

[Bug optimization/14848] [tree-ssa] prefer EQ_EXPR and NE_EXPR to ordered comparisons

[dnovillo at redhat dot com]

------- Additional Comments From dnovillo at redhat dot com  2004-04-08 23:08 -------
Subject: Re:  [tree-ssa] prefer EQ_EXPR and NE_EXPR
	to ordered comparisons

On Thu, 2004-04-08 at 18:53, law at redhat dot com wrote:

> Interestingly it also fixes a couple of the execute/loop-blah.c failures
> probably because we pass slightly better trees down to the RTL optimizers
> and thus avoiding some latent backend bug.
> 
Excellent.

> It initially appeared that the patch was causing 12658_thread.cc to 
> regress.  However, further testing has shown that 12658_thread.cc appears
> to randomly fail -- same binary works sometimes and fails other times.
> That behavior is independent of this patch.
> 
Yes.  12658_thread.cc is very volatile.  I get the same behaviour out of
it.


Diego.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14848

[Bug optimization/14848] [tree-ssa] prefer EQ_EXPR and NE_EXPR to ordered comparisons

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-08 23:16 -------
And this is can be closed as fixed as the patch was applied.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14848