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