llvm-svn: 22889

llvm-svn: 22888

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

llvm-svn: 22887

passed.

llvm-svn: 22886

or not it's variable.

llvm-svn: 22885

llvm-svn: 22884

the operand lists of a few other nodes.

llvm-svn: 22883

llvm-svn: 22882

llvm-svn: 22881

llvm-svn: 22880

LLVM is able to merge identical static const globals, GCC isn't, and this caused
some bloat in the generated data.  This has a marginal effect on PPC, shrinking
the implicit sets from 10->4, but shrinks X86 from 179 to 23, a much bigger
reduction.

This should speed up the register allocator as well by reducing the dcache
footprint for this static data.

llvm-svn: 22879

llvm-svn: 22878

llvm-svn: 22877

codegen:

_empty:
.LBB_empty_0:   ;
        blr

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

llvm-svn: 22876

llvm-svn: 22875

llvm-svn: 22874

.td file.

llvm-svn: 22873

2. Get an exact count of 'li ' instructions.

llvm-svn: 22872

llvm-svn: 22871

llvm-svn: 22870

llvm-svn: 22869

llvm-svn: 22868

llvm-svn: 22867

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

zextload + sign_extend_inreg rather than a sextload.

llvm-svn: 22852

llvm-svn: 22851

llvm-svn: 22850

llvm-svn: 22849

llvm-svn: 22848

llvm-svn: 22847