the 177.mesa failure from last night, and fixes the
CodeGen/PowerPC/2005-10-08-ArithmeticRotate.ll regression test I added.
If this code cannot be fixed, it should be removed for good, but I'll leave
it to Nate to decide its fate.
llvm-svn: 23670
is faster and uses less stack space. This reduces our stack requirement
enough to compile sixtrack, and though it's a hack, should be enough until
we switch to iterative isel
llvm-svn: 23664
helps but not enough.
Start pulling cases out of PPC32DAGToDAGISel::Select. With GCC 4, this function
required 8512 bytes of stack space for each invocation (GCC 3 required less
than 700 bytes). Pulling this first function out gets us down to 8224. More
to come :(
llvm-svn: 23647
we're in a single-mbb loop, make sure to emit the backwards branch as the
conditional branch instead of the uncond branch. For example, emit this:
LBBl29_z__44:
stw r9, 0(r15)
stw r9, 4(r15)
stw r9, 8(r15)
stw r9, 12(r15)
addi r15, r15, 16
addi r8, r8, 1
cmpw cr0, r8, r28
ble cr0, LBBl29_z__44
b LBBl29_z__48 *** NOT PART OF LOOP
Instead of:
LBBl29_z__44:
stw r9, 0(r15)
stw r9, 4(r15)
stw r9, 8(r15)
stw r9, 12(r15)
addi r15, r15, 16
addi r8, r8, 1
cmpw cr0, r8, r28
bgt cr0, LBBl29_z__48 *** PART OF LOOP!
b LBBl29_z__44
The former sequence has one fewer dispatch group for the loop body.
llvm-svn: 23582
are allowed to generate 64-bit-only PowerPC instructions for 32 bit hosts,
such as the PowerPC 970.
This speeds up 189.lucas from 81.99 to 32.64 seconds.
llvm-svn: 23250
directly out of R1 (without using a CopyFromReg, which uses a chain), multiple
allocas were getting CSE'd together, producing bogus code. For this:
int %foo(bool %X, int %A, int %B) {
br bool %X, label %T, label %F
F:
%G = alloca int
%H = alloca int
store int %A, int* %G
store int %B, int* %H
%R = load int* %G
ret int %R
T:
ret int 0
}
We were generating:
_foo:
stwu r1, -16(r1)
stw r31, 4(r1)
or r31, r1, r1
stw r1, 12(r31)
cmpwi cr0, r3, 0
bne cr0, .LBB_foo_2 ; T
.LBB_foo_1: ; F
li r2, 16
subf r2, r2, r1 ;; One alloca
or r1, r2, r2
or r3, r1, r1
or r1, r2, r2
or r2, r1, r1
stw r4, 0(r3)
stw r5, 0(r2)
lwz r3, 0(r3)
lwz r1, 12(r31)
lwz r31, 4(r31)
lwz r1, 0(r1)
blr
.LBB_foo_2: ; T
li r3, 0
lwz r1, 12(r31)
lwz r31, 4(r31)
lwz r1, 0(r1)
blr
Now we generate:
_foo:
stwu r1, -16(r1)
stw r31, 4(r1)
or r31, r1, r1
stw r1, 12(r31)
cmpwi cr0, r3, 0
bne cr0, .LBB_foo_2 ; T
.LBB_foo_1: ; F
or r2, r1, r1
li r3, 16
subf r2, r3, r2 ;; Alloca 1
or r1, r2, r2
or r2, r1, r1
or r6, r1, r1
subf r3, r3, r6 ;; Alloca 2
or r1, r3, r3
or r3, r1, r1
stw r4, 0(r2)
stw r5, 0(r3)
lwz r3, 0(r2)
lwz r1, 12(r31)
lwz r31, 4(r31)
lwz r1, 0(r1)
blr
.LBB_foo_2: ; T
li r3, 0
lwz r1, 12(r31)
lwz r31, 4(r31)
lwz r1, 0(r1)
blr
This fixes Povray and SPASS with the dag isel, the last two failing cases.
Tommorow we will hopefully turn it on by default! :)
llvm-svn: 23190
could cause a miscompile. Fixing this didn't fix the two programs that fail
though. :(
This also changes the implementation to follow the pattern selector more
closely, causing us to select 0 to li instead of lis.
llvm-svn: 23189
Remove code (last hunk) that miscompiled immediate and's, such as
and uint %tmp.30, 4294958079
into
andi. r8, r8, 56319
andis. r8, r8, 65535
instead of:
li r9, -9217
and r8, r8, r9
The first always generates zero.
This fixes espresso.
llvm-svn: 23155
linking them to calls when appropriate, this prevents the scheduler from
pulling these copies away from the call.
This fixes Ptrdist/yacr2
llvm-svn: 23143
