[Bug target/54829] bad optimization: sub followed by cmp w/ zero (x86 & ARM)

["daniel.santos at pobox dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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.