public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "rearnsha at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/54829] bad optimization: sub followed by cmp w/ zero (x86 & ARM)
Date: Mon, 05 Aug 2013 21:04:00 -0000	[thread overview]
Message-ID: <bug-54829-4-wTkSXjENhB@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-54829-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #8 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
(In reply to Daniel Santos from comment #7)
> First off, I apologize for my late response here.
> 
> (In reply to comment #5)
> I'm going to respond a little backwards..
> 
> > In fact, on ARM there is no branch instruction that can be used for "> 0" as a
> > side effect of a subtract.  To get the desired effect the code would have to be
> > completely re-arranged to factor out the "< 0" (bmi) and then "== 0" (beq)
> > cases first.
> 
> I'm not an ARM programmer, but I'm looking at my reference book and it would
> appear that BGT would perform a branch of greater than for signed comparison
> and and BHI for unsigned comparison.  Again, convert the subtraction into a
> comparison (subtract, but discard the result) and branch based upon the
> flags (for signed numbers):
> 
>     cmp    r0, r1
>     bgt    .L1
>     bne    .L2
> ;handle equality here
> 

Unfortunately, computers don't to infinite precision arithmetic by default. 
That would perform a different comparison in that it checks that r0 > r1, not
whether r0 - r1 > 0.  The difference, for signed comparisons, is when overflow
occurs.

Consider the case where (in your original code) a has the value INT_MIN (ie
-2147483648) and b has the value 1.

Now clearly a < b and by the normal rules of arithmetic (infinite precision) we
would expect a - b to be less than zero.

However, INT_MIN - 1 cannot be represented in a 32-bit long value and becomes
INT_MAX due to overflow; the result is that for these values a - b > 0!

On ARM and x86, the flag setting that results from a subtract operation is, in
effect a comparison of the original operands, rather than a comparison of the
result; that is on ARM

   subs rd, rn, rm

is equivalent to 

   cmp rn, rm

except that the register rd is not written by the comparison.

Power PC is different: it's subtract and compare instruction really does use
the result of the subtraction to form the comparison.


  parent reply	other threads:[~2013-08-05 21:04 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-05 23:16 [Bug target/54829] New: " daniel.santos at pobox dot com
2012-10-05 23:40 ` [Bug target/54829] " pinskia at gcc dot gnu.org
2012-10-06 13:31 ` [Bug target/54829] bad optimization: sub followed by cmp w/ zero (ARM) hjl.tools at gmail dot com
2012-10-06 15:56 ` [Bug target/54829] bad optimization: sub followed by cmp w/ zero (x86 & ARM) daniel.santos at pobox dot com
2012-10-06 15:57 ` daniel.santos at pobox dot com
2012-10-13 16:05 ` rearnsha at gcc dot gnu.org
2012-10-13 16:18 ` rearnsha at gcc dot gnu.org
2012-11-15 21:56 ` daniel.santos at pobox dot com
2013-08-05 21:04 ` rearnsha at gcc dot gnu.org [this message]
2015-02-15  6:17 ` daniel.santos at pobox dot com

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=bug-54829-4-wTkSXjENhB@http.gcc.gnu.org/bugzilla/ \
    --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).