the code in question is now:

cmpw cr0, r7, r3
        ble cr0, LBB1_5 ;bb25
LBB1_8: ;bb17
        cmpw cr0, r8, r5
        bgt cr0, LBB1_2 ;bb

which is just as good as crnand.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@31235 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Chris Lattner 2006-10-27 22:00:55 +00:00
parent 9286cd3e9b
commit 4ccf63d8cf

View File

@ -150,36 +150,6 @@ Probably not a win on x86.
===-------------------------------------------------------------------------===
PowerPC i1/setcc stuff (depends on subreg stuff):
Check out the PPC code we get for 'compare' in this testcase:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19672
oof. on top of not doing the logical crnand instead of (mfcr, mfcr,
invert, invert, or), we then have to compare it against zero instead of
using the value already in a CR!
that should be something like
cmpw cr7, r8, r5
cmpw cr0, r7, r3
crnand cr0, cr0, cr7
bne cr0, LBB_compare_4
instead of
cmpw cr7, r8, r5
cmpw cr0, r7, r3
mfcr r7, 1
mcrf cr7, cr0
mfcr r8, 1
rlwinm r7, r7, 30, 31, 31
rlwinm r8, r8, 30, 31, 31
xori r7, r7, 1
xori r8, r8, 1
addi r2, r2, 1
or r7, r8, r7
cmpwi cr0, r7, 0
bne cr0, LBB_compare_4 ; loopexit
FreeBench/mason has a basic block that looks like this:
%tmp.130 = seteq int %p.0__, 5 ; <bool> [#uses=1]