public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug optimization/14848] New: [tree-ssa] prefer EQ_EXPR and NE_EXPR to ordered comparisons @ 2004-04-04 17:28 kazu at cs dot umass dot edu 2004-04-04 17:38 ` [Bug optimization/14848] " pinskia at gcc dot gnu dot org ` (5 more replies) 0 siblings, 6 replies; 7+ messages in thread From: kazu at cs dot umass dot edu @ 2004-04-04 17:28 UTC (permalink / raw) To: gcc-bugs 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug optimization/14848] [tree-ssa] prefer EQ_EXPR and NE_EXPR to ordered comparisons 2004-04-04 17:28 [Bug optimization/14848] New: [tree-ssa] prefer EQ_EXPR and NE_EXPR to ordered comparisons kazu at cs dot umass dot edu @ 2004-04-04 17:38 ` pinskia at gcc dot gnu dot org 2004-04-06 19:18 ` pinskia at gcc dot gnu dot org ` (4 subsequent siblings) 5 siblings, 0 replies; 7+ messages in thread From: pinskia at gcc dot gnu dot org @ 2004-04-04 17:38 UTC (permalink / raw) To: gcc-bugs ------- 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug optimization/14848] [tree-ssa] prefer EQ_EXPR and NE_EXPR to ordered comparisons 2004-04-04 17:28 [Bug optimization/14848] New: [tree-ssa] prefer EQ_EXPR and NE_EXPR to ordered comparisons 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 ` (3 subsequent siblings) 5 siblings, 0 replies; 7+ messages in thread From: pinskia at gcc dot gnu dot org @ 2004-04-06 19:18 UTC (permalink / raw) To: gcc-bugs ------- 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug optimization/14848] [tree-ssa] prefer EQ_EXPR and NE_EXPR to ordered comparisons 2004-04-04 17:28 [Bug optimization/14848] New: [tree-ssa] prefer EQ_EXPR and NE_EXPR to ordered comparisons 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 ` (2 subsequent siblings) 5 siblings, 0 replies; 7+ messages in thread From: law at gcc dot gnu dot org @ 2004-04-07 18:25 UTC (permalink / raw) To: gcc-bugs ------- 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug optimization/14848] [tree-ssa] prefer EQ_EXPR and NE_EXPR to ordered comparisons 2004-04-04 17:28 [Bug optimization/14848] New: [tree-ssa] prefer EQ_EXPR and NE_EXPR to ordered comparisons kazu at cs dot umass dot edu ` (2 preceding siblings ...) 2004-04-07 18:25 ` law at gcc dot gnu dot org @ 2004-04-08 22:53 ` law at redhat dot com 2004-04-08 23:08 ` dnovillo at redhat dot com 2004-04-08 23:16 ` pinskia at gcc dot gnu dot org 5 siblings, 0 replies; 7+ messages in thread From: law at redhat dot com @ 2004-04-08 22:53 UTC (permalink / raw) To: gcc-bugs ------- 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug optimization/14848] [tree-ssa] prefer EQ_EXPR and NE_EXPR to ordered comparisons 2004-04-04 17:28 [Bug optimization/14848] New: [tree-ssa] prefer EQ_EXPR and NE_EXPR to ordered comparisons kazu at cs dot umass dot edu ` (3 preceding siblings ...) 2004-04-08 22:53 ` law at redhat dot com @ 2004-04-08 23:08 ` dnovillo at redhat dot com 2004-04-08 23:16 ` pinskia at gcc dot gnu dot org 5 siblings, 0 replies; 7+ messages in thread From: dnovillo at redhat dot com @ 2004-04-08 23:08 UTC (permalink / raw) To: gcc-bugs ------- 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug optimization/14848] [tree-ssa] prefer EQ_EXPR and NE_EXPR to ordered comparisons 2004-04-04 17:28 [Bug optimization/14848] New: [tree-ssa] prefer EQ_EXPR and NE_EXPR to ordered comparisons kazu at cs dot umass dot edu ` (4 preceding siblings ...) 2004-04-08 23:08 ` dnovillo at redhat dot com @ 2004-04-08 23:16 ` pinskia at gcc dot gnu dot org 5 siblings, 0 replies; 7+ messages in thread From: pinskia at gcc dot gnu dot org @ 2004-04-08 23:16 UTC (permalink / raw) To: gcc-bugs ------- 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2004-04-08 23:16 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-04-04 17:28 [Bug optimization/14848] New: [tree-ssa] prefer EQ_EXPR and NE_EXPR to ordered comparisons 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 2004-04-08 23:08 ` dnovillo at redhat dot com 2004-04-08 23:16 ` pinskia at gcc dot gnu dot org
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).