Back out Owen's 6/9 changes. They broke MultiSource/Benchmarks/Prolangs-C/bison (and perhaps others).

llvm-svn: 28747

LCSSA.

llvm-svn: 28739

on this.

llvm-svn: 28738

post-increment value, should be first cast to the appropriated type (to the
type of the common expr). Otherwise, the rewrite of a use based on (common +
iv) may end up with an incorrect type.

llvm-svn: 28735

require LCSSA.

llvm-svn: 28734

llvm-svn: 28714

PPC/altivec

llvm-svn: 28698

llvm-svn: 28694

llvm-svn: 28693

llvm-svn: 28680

llvm-svn: 28678

actually going on.

llvm-svn: 28677

llvm-svn: 28664

to link in the implementation.  Thanks to Anton Korobeynikov for figuring out
what was going on here.

llvm-svn: 28660

llvm-svn: 28642

code (while cloning) it often gets the branch/switch instructions.  Since it
knows that edges of the CFG are dead, it need not clone (or even look) at
the obviously dead blocks.  This should speed up the inliner substantially on
code where there are lots of inlinable calls to functions with constant
arguments.  On C++ code in particular, this kicks in.

llvm-svn: 28641

llvm-svn: 28632

llvm-svn: 28619

reimplement getValueDominatingFunction to walk the DominanceTree rather than
just searching blindly.

llvm-svn: 28618

but for sub, it really does!  Fix fixes a miscompilation of fibheap_cut in
llvmgcc4.

llvm-svn: 28600

llvm-svn: 28599

is now theoretically feature-complete.  It has not, however, been thoroughly
test, and is still considered experimental.

llvm-svn: 28529

other calculations on each individually, rather than trying to delay it and do
them all at the end.

llvm-svn: 28527

the iterated Dominance Frontier of the loop-closure Phi's.  This is the
second phase of the LCSSA pass.  The third phase (coming soon) will be to
update all uses of loop variables to use the loop-closure Phi's instead.

llvm-svn: 28524

ldecod, lencod, and SPASS.

llvm-svn: 28523

makes it so that it constant folds instructions on the fly.  This is good
for several reasons:

0. Many instructions are constant foldable after inlining, particularly if
   inlining a call with constant arguments.
1. Without this, the inliner has to allocate memory for all of the instructions
   that can be constant folded, then a subsequent pass has to delete them.  This
   gets the job done without this extra work.
2. This makes the inliner *pass* a bit more aggressive: in particular, it
   partially solves a phase order issue where the inliner would inline lots
   of code that folds away to nothing, but think that the resultant function
   is big because of this code that will be gone.  Now the code never exists.

This is the first part of a 2-step process.  The second part will be smart
enough to see when this implicit constant folding propagates a constant into
a branch or switch instruction, making CFG edges dead.

This implements Transforms/Inline/inline_constprop.ll

llvm-svn: 28521

llvm-svn: 28519

Refactor some code to expose an interface to constant fold and instruction given it's opcode, typeand operands.

llvm-svn: 28517

llvm-svn: 28512

llvm-svn: 28507

there's still a lot of work to be done on it.

llvm-svn: 28506

llvm-svn: 28503

and documentation updates soo.

llvm-svn: 28495

llvm-svn: 28490

No functionality change.

llvm-svn: 28489

the program.  This exposes more opportunities for the instcombiner, and implements
vec_shuffle.ll:test6

llvm-svn: 28487

extractelement from the SV's source.  This implement vec_shuffle.ll:test[45]

llvm-svn: 28485

array scopes possibly accessing valid memory in outer subscripts.

llvm-svn: 28478

This implements Transforms/InstCombine/2006-05-10-InvalidIndexUndef.ll

llvm-svn: 28450

by Anton Korobeynikov!  This is a step towards closing PR786.

llvm-svn: 28447