public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "law at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug optimization/14848] [tree-ssa] prefer EQ_EXPR and NE_EXPR to ordered comparisons
Date: Thu, 08 Apr 2004 22:53:00 -0000	[thread overview]
Message-ID: <20040408225300.983.qmail@sources.redhat.com> (raw)
In-Reply-To: <20040404172846.14848.kazu@cs.umass.edu>


------- 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


  parent reply	other threads:[~2004-04-08 22:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-04 17:28 [Bug optimization/14848] New: " kazu at cs dot umass dot edu
2004-04-04 17:38 ` [Bug optimization/14848] " pinskia at gcc dot gnu dot org
2004-04-06 19:18 ` pinskia at gcc dot gnu dot org
2004-04-07 18:25 ` law at gcc dot gnu dot org
2004-04-08 22:53 ` law at redhat dot com [this message]
2004-04-08 23:08 ` dnovillo at redhat dot com
2004-04-08 23:16 ` pinskia at gcc dot gnu dot org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040408225300.983.qmail@sources.redhat.com \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).