llvm-svn: 23700

out CSE's of base expressions it could build a result whose order was
nondet.

llvm-svn: 23698

from the end of a vector instead of the beginning

llvm-svn: 23697

llvm-svn: 23695

llvm-svn: 23694

llvm-svn: 23693

llvm-svn: 23692

location, replace them with a new store of the last value.  This occurs
in the same neighborhood in 197.parser, speeding it up about 1.5%

llvm-svn: 23691

multiple results.

Use this support to implement trivial store->load forwarding, implementing
CodeGen/PowerPC/store-load-fwd.ll.  Though this is the most simple case and
can be extended in the future, it is still useful.  For example, it speeds
up 197.parser by 6.2% by avoiding an LSU reject in xalloc:

        stw r6, lo16(l5_end_of_array)(r2)
        addi r2, r5, -4
        stwx r5, r4, r2
-       lwzx r5, r4, r2
-       rlwinm r5, r5, 0, 0, 30
        stwx r5, r4, r2
        lwz r2, -4(r4)
        ori r2, r2, 1

llvm-svn: 23690

sext_inreg into zext_inreg based on the signbit (fires a lot), srem into
urem, etc.

llvm-svn: 23688

llvm-svn: 23686

llvm-svn: 23685

llvm-svn: 23684

removal of a bunch of ad-hoc and crufty code from SelectionDAG.cpp.

llvm-svn: 23682

llvm-svn: 23681

can be used by other targets.  For those targets that want to use it,
have at.  :)

llvm-svn: 23680

llvm-svn: 23679

llvm-svn: 23678

llvm-svn: 23677

This seems useful from the original patch that added the function.  If there is a reason it is not useful on a RISC type target, let me know and I will pull it out

llvm-svn: 23676

llvm-svn: 23674

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