llvm-svn: 23673

IV strides dependend on the pointer order of the strides in memory.
Non-determinism is bad.

llvm-svn: 23672

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

merge, and using subtarget info for ptr size.

llvm-svn: 23668

llvm-svn: 23666

llvm-svn: 23665

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

llvm-svn: 23663

C-X's

llvm-svn: 23662

llvm-svn: 23660

implements CodeGen/PowerPC/div-2.ll

llvm-svn: 23659

llvm-svn: 23656

this out to me

llvm-svn: 23655

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

llvm-svn: 23652

llvm-svn: 23650

llvm-svn: 23649

llvm-svn: 23648

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

llvm-svn: 23646

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

llvm-svn: 23644

llvm-svn: 23643

llvm-svn: 23642

llvm-svn: 23641

llvm-svn: 23640

llvm-svn: 23639

  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

llvm-svn: 23637

with the dag combiner.  This speeds up espresso by 8%, reaching performance
parity with the dag-combiner-disabled llc.

llvm-svn: 23636

llvm-svn: 23635

dead node elim and dag combiner passes where the root is potentially updated.
This fixes a fixme in the dag combiner.

llvm-svn: 23634

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

the second phase of dag combining

llvm-svn: 23631

llvm-svn: 23630

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

of the python test from 1:00 to 54s.

llvm-svn: 23627

true dynamically.  Finally, pass the Use* that replaceAllUsesWith has into
the method for future use.

llvm-svn: 23626

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