LCSSA is still the slowest pass when gccas'ing 252.eon, but now it only takes
39s instead of 289s. :)

llvm-svn: 28776

llvm-svn: 28774

not handling PHI nodes correctly when determining if a value was live-out.

This patch reduces the number of detected live-out variables in the testcase
from 6565 to 485.

llvm-svn: 28771

llvm-svn: 28758

If a single exit block has multiple predecessors within the loop, it will
appear in the exit blocks list more than once.  LCSSA needs to take that into
account so that it doesn't double process that exit block.

llvm-svn: 28750

llvm-svn: 28748

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

llvm-svn: 28747

on this.

llvm-svn: 28738

require LCSSA.

llvm-svn: 28734

llvm-svn: 28694

llvm-svn: 28693

llvm-svn: 28680

llvm-svn: 28678

actually going on.

llvm-svn: 28677

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: 28619

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

llvm-svn: 28618

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

and documentation updates soo.

llvm-svn: 28495

array scopes possibly accessing valid memory in outer subscripts.

llvm-svn: 28478

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

llvm-svn: 28450

llvm-svn: 28395

to the new module.  Patch provided by Nick Lewycky!

llvm-svn: 28349

llvm-svn: 28289

llvm-svn: 28286

Domagoj Babic!

llvm-svn: 28181

nondeterminism being bad) could cause some trivial missed optimizations (dead
phi nodes being left around for later passes to clean up).

With this, llvm-gcc4 now bootstraps and correctly compares.  I don't know
why I never tried to do it before... :)

llvm-svn: 27984

llvm-svn: 27513