llvm-svn: 22907

(which died about a week ago) so we're back to load-(2^n-1)-then-AND
sequences. slow, but things should now be Almost Completely Working,
modulo those pesky alignment/ABI issues.

llvm-svn: 22904

llvm-svn: 22902

instruction.

llvm-svn: 22901

llvm-svn: 22896

cleanest backend in this metric :)

llvm-svn: 22893

I'm not convinced this is all of them,  but I can't do much testing, because
IA64 LLC crashes on big programs :(

llvm-svn: 22892

llvm-svn: 22891

Give a whole bunch of other stuff variable operands, particularly FP.  The
FP stackifier is playing fast and loose with operands here, so we have to
mark them all as variable.  This will have to be fixed before we can dag->dag
the X86 backend.  The solution is for the pre-stackifier and post-stackifier
instructions to all be disjoint.

llvm-svn: 22890

llvm-svn: 22889

llvm-svn: 22888

only take one operand.  The other comes implicitly in through CL.

llvm-svn: 22887

passed.

llvm-svn: 22886

llvm-svn: 22884

the operand lists of a few other nodes.

llvm-svn: 22883

llvm-svn: 22882

llvm-svn: 22881

llvm-svn: 22878

llvm-svn: 22877

codegen:

_empty:
.LBB_empty_0:   ;
        blr

but can't do anything more (yet). :)

llvm-svn: 22876

llvm-svn: 22870

llvm-svn: 22869

llvm-svn: 22868

llvm-svn: 22866

as the argument to LIS rather than the result of HA16(constant).

The DAG->DAG ISel was already doing the right thing.

llvm-svn: 22865

Now for int foo() { return -1; } we generate:
_foo:
        li r3, -1
        blr

instead of
_foo:
        lis r2, -1
        ori r3, r2, 65535
        blr

llvm-svn: 22864

llvm-svn: 22863

to make the code follow people's expectations better.

llvm-svn: 22861

llvm-svn: 22858

llvm-svn: 22857

rlwinm.

llvm-svn: 22856

llvm-svn: 22855

llvm-svn: 22854

llvm-svn: 22853

llvm-svn: 22851

llvm-svn: 22850

llvm-svn: 22849

llvm-svn: 22848

several of the PowerPC opcodes that come in both negated and non-negated
forms.

llvm-svn: 22845

on 177.mesa

llvm-svn: 22843