From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18638 invoked by alias); 15 Nov 2012 21:56:39 -0000 Received: (qmail 16983 invoked by uid 48); 15 Nov 2012 21:56:05 -0000 From: "daniel.santos at pobox dot com" 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 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: enhancement X-Bugzilla-Who: daniel.santos at pobox dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-11/txt/msg01456.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54829 --- Comment #7 from Daniel Santos 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.