This completes the grand PPC file renaming

llvm-svn: 23745

and PPC32JITInfo classes should be merged.

llvm-svn: 23744

llvm-svn: 23743

llvm-svn: 23742

still should be merged into the PPC32TargetMachine class

llvm-svn: 23741

llvm-svn: 23740

llvm-svn: 23739

llvm-svn: 23738

llvm-svn: 23737

from the .td file that correspond to it

llvm-svn: 23736

fixing a bunch of nasty hackery

llvm-svn: 23735

We will decide with subtarget support whether we ever use an i64 register
class.

llvm-svn: 23734

llvm-svn: 23733

llvm-svn: 23731

llvm-svn: 23727

llvm-svn: 23726

popping up in Fourinarow.

llvm-svn: 23722

llvm-svn: 23721

you could be AND'ing with the result of a shift that shifts out all the
bits you care about, in addition to a constant.

Also, move over an add/sub_parts fold from legalize to the dag combiner,
where it works for things other than constants.  Woot!

llvm-svn: 23720

llvm-svn: 23718

llvm-svn: 23717

is also legal.  Add support for ExpandOp'ing raw EXTLOADs too.

llvm-svn: 23716

llvm-svn: 23715

the remainder of the failures introduced by my patch last night.

llvm-svn: 23714

tests.

llvm-svn: 23713

parts. This should fix the crafty and signed long long unit test failure
on x86 last night.

llvm-svn: 23711

minimize unnecessary spilling.

llvm-svn: 23710

Kill some dead code.

llvm-svn: 23706

out, where after the first CombineTo() call, the node the second CombineTo
wishes to replace may no longer exist.

Fix a very real bug with the truncated load optimization on little endian
targets, which do not need a byte offset added to the load.

llvm-svn: 23704

like turning:

_foo:
        fctiwz f0, f1
        stfd f0, -8(r1)
        lwz r2, -4(r1)
        rlwinm r3, r2, 0, 16, 31
        blr

into
_foo:
        fctiwz f0,f1
        stfd f0,-8(r1)
        lhz r3,-2(r1)
        blr

Also removed an unncessary constraint from sra -> srl conversion, which
should take care of hte only reason we would ever need to handle sra in
MaskedValueIsZero, AFAIK.

llvm-svn: 23703

llvm-svn: 23702

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