Make sure IPSCCP never marks a tracked call as overdefined in SCCPSolver::ResolvedUndefsIn.  If we do, we can end up in a situation where a function is resolved to return a constant, but the caller is marked overdefined, which confuses the code later.

<rdar://problem/9956541> (again).

llvm-svn: 140210

llvm-svn: 139842

which could theoretically throw.

llvm-svn: 139710

in memory relevant to the optimizer. rdar://10050579.

llvm-svn: 139708

llvm-svn: 139583

llvm-svn: 139579

llvm-svn: 139574

llvm-svn: 139571

llvm-svn: 139565

No tests; these changes aren't really interesting in the sense that the logic is the same for volatile and atomic.

I believe this completes all of the changes necessary for the optimizer to handle loads and stores correctly.  I'm going to try and come up with some additional testing, though.

llvm-svn: 139533

llvm-svn: 139517

better.

Don't immediately give up when an add operation can't be trivially
sign/zero-extended within a loop. If it has NSW/NUW flags, generate a
new expression with sign extended (non-recurrent) operand. As before,
if SCEV says that all sign extends are loop invariant, then we can
widen the operation.

llvm-svn: 139453

llvm-svn: 139375

llvm-svn: 139169

llvm-svn: 139156

Try again at r138809 (make DSE more aggressive in removing dead stores at the end of a function), now with less deleting stores before memcpy's.

llvm-svn: 139150

Use Duncan's patch to delete the instructions in reverse order (minus the landingpad and terminator).

llvm-svn: 139090

llvm-svn: 139023

This changes loop unrolling to use the same mechanism for trip count
computation as indvars. This is a stronger check that tends to unroll
more loops. A very common side-effect is that many single iteration
loops will be removed sooner. The real goal was simply to remove
dependence on canonical IVs.

x86 is break even.
ARM performance changes to expect (+ is good):
External/SPEC/CFP2000/183.equake/183.equake +13%
SingleSource/Benchmarks/Dhrystone/fldry     +21%
MultiSource/Applications/spiff/spiff         +3%
SingleSource/Benchmarks/Stanford/Puzzle     -14%

The Puzzle regression is actually an improvement in loop optimization
that defeats GVN: rdar://problem/10065079.

llvm-svn: 139009

will be valid. This fixes PR10820.

llvm-svn: 139005

Duncan noticed this!

llvm-svn: 138967

Fix an issue with the IR sink pass found by inspection.  (I'm not sure anyone is actually using this, but might as well fix it since I found the issue.)

llvm-svn: 138965

The landingpad instruction is required in the landing pad block. Because we're
not deleting terminating instructions, the invoke may still jump to here (see
Transforms/SCCP/2004-11-16-DeadInvoke.ll). Remove all uses of the landingpad
instruction, but keep it around until code-gen can remove the basic block.

llvm-svn: 138890

ssa, so it has to be run really early in the pipeline. Any replacement
should probably use the SSAUpdater.

llvm-svn: 138841

llvm-svn: 138829

When walking backwards to eliminate final stores to allocas at the end of a function, encountering an unrelated store should not cause us to give up like encountering a load does.

llvm-svn: 138809

llvm-svn: 138651

proper function to do it.

llvm-svn: 138550

getFirstNonPHI so that it will skip over the landingpad instructions as well.

llvm-svn: 138537

llvm-svn: 138481

insertion place.

llvm-svn: 138473

llvm-svn: 138243

llvm-svn: 138242

llvm-svn: 138102

llvm-svn: 138025

known-incremented level, because the two concepts can be used
to prove the saftey of a retain+release removal in different
ways.

llvm-svn: 138016

llvm-svn: 138008

llvm-svn: 137985

Dramatically speedup codegen prepare by a) avoiding use of dominator tree and b) doing a separate pass over dbg.value instructions.

llvm-svn: 137908

llvm-svn: 137888