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
next prev 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: linkBe 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).