creating a new vreg and inserting a copy: just use the input vreg directly.
This speeds up the compile (e.g. about 5% on mesa with a debug build of llc)
by not adding a bunch of copies and vregs to be coallesced away. On mesa,
for example, this reduces the number of intervals from 168601 to 129040
going into the coallescer.
llvm-svn: 23671
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
classes on PPC. We were emitting fmr instructions to do fp extensions, which
weren't getting coallesced. This fixes Regression/CodeGen/PowerPC/fpcopy.ll
llvm-svn: 23654
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
previous copy elisions and we discover we need to reload a register, make
sure to use the regclass of the original register for the reload, not the
class of the current register. This avoid using 16-bit loads to reload 32-bit
values.
llvm-svn: 23645
store r12 -> [ss#2]
R3 = load [ss#1]
use R3
R3 = load [ss#2]
R4 = load [ss#1]
and turn it into this code:
store R12 -> [ss#2]
R3 = load [ss#1]
use R3
R3 = R12
R4 = R3 <- oops!
The problem was that promoting R3 = load[ss#2] to a copy missed the fact that
the instruction invalidated R3 at that point.
llvm-svn: 23638
that testcase still does not pass with the dag combiner. This is because
not all forms of br* are folded yet.
Also, when we combine a node into another one, delete the node immediately
instead of waiting for the node to potentially come up in the future.
llvm-svn: 23632
When moving constant entries in 'Map' if the entry is the representative
constant for the abstractypemap, make sure to update it as well. This
fixes the bcreader failures from last night on several C++ apps.
llvm-svn: 23628
creating the keys and doing comparisons to index into 'Map' takes a lot
of time. For these large constants, keep an inverse map so that 'remove'
and move operations are much faster.
This speeds up a release build of the bc reader on Eric's nasty python
bytecode file from 1:39 to 1:00s.
llvm-svn: 23624
