public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "daniel.santos at pobox dot com" <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: Thu, 15 Nov 2012 21:56:00 -0000 [thread overview] Message-ID: <bug-54829-4-XTWbU4MaGU@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 #7 from Daniel Santos <daniel.santos at pobox dot com> 2012-11-15 21:56:02 UTC --- 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 Alternately, if the code to execute for each condition will not change the result flags, then the use of condition instructions could replace the branches. In this example there is no need to check for equality because the previous two branch instructions eliminate all other possibilities. The reason that my C code example above does *not* check for equality is that it is the least likely condition and can be determined by eliminating the two most likely conditions (negative or positive and not equal). > The result of the comparison is used in more than one instruction, so combine > cannot safely rework the branch instructions that follow to ensure that the > result of the subtract is used correctly. I suppose I'm going to have to learn the gcc internals. It will probably be good for me anyway. However, If what you say is correct, then the *problem* lies at a higher level than the "combine", but it does not invalidate the problem its self. Where do we make the decision that a result can be discarded? That would seem to be where the cause of this problem lies. So to break it down more accurately, if all of these conditions are true: 1.) we perform an integral subtraction, 2.) and every use of the result can be replaced with fewer instructions that use the CPU flags that were changed by the subtraction instead of the result its self, 3.) and no instructions between the subtraction and the last use of its result modify those flags then we should replace the subtract operation with a compare and use the CPU flags instead. I am not aware of any case, when both a and b are of the same signed integral type, where "(a - b) > 0" and "(a - b) < 0" cannot be replaced with "a > b" and "a < b", respectively.
next prev parent reply other threads:[~2012-11-15 21:56 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 [this message] 2013-08-05 21:04 ` rearnsha at gcc dot gnu.org 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-XTWbU4MaGU@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: 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).