branch "br i1 %x, label %if_true, label %if_false" then it replaces
"%x" with "true" in places only reachable via the %if_true arm, and
with "false" in places only reachable via the %if_false arm.  Except
that actually it doesn't: if value numbering shows that %y is equal
to %x then, yes, %y will be turned into true/false in this way, but
any occurrences of %x itself are not transformed.  Fix this.  What's
more, it's often the case that %x is an equality comparison such as
"%x = icmp eq %A, 0", in which case every occurrence of %A that is
only reachable via the %if_true arm can be replaced with 0.  Implement
this and a few other variations on this theme.  This reduces the number
of lines of LLVM IR in "GCC as one big file" by 0.2%.  It has a bigger
impact on Ada code, typically reducing the number of lines of bitcode
by around 0.4% by removing repeated compiler generated checks.  Passes
the LLVM nightly testsuite and the Ada ACATS testsuite.

llvm-svn: 141177

it's OK for the false/true destination to have multiple
predecessors as long as the extra ones are dominated by
the branch destination.

llvm-svn: 141176

This handles the case in which LSR rewrites an IV user that is a phi and
splits critical edges originating from a switch.
Fixes <rdar://problem/6453893> LSR is not splitting edges "nicely"

llvm-svn: 141059

We want heuristics to be based on accurate data, but more importantly
we don't want llvm to behave randomly. A benign trunc inserted by an
upstream pass should not cause a wild swings in optimization
level. See PR11034. It's a general problem with threshold-based
heuristics, but we can make it less bad.

llvm-svn: 140919

llvm-svn: 140821

handle the case where the retain is in a different basic block.
rdar://10210274.

llvm-svn: 140815

objc_retainBlock call is potentially responsible for copying
the block to the heap to extend its lifetime. rdar://10209613.

llvm-svn: 140814

llvm-svn: 140769

Rewriting the entire loop nest now requires -enable-lsr-nested.
See PR11035 for some performance data.
A few unit tests specifically test nested LSR, and are now under a flag.

llvm-svn: 140762

llvm-svn: 140670

Stop emitting instructions with the name "tmp" they eat up memory and have to be uniqued, without any benefit.

If someone prefers %tmp42 to %42, run instnamer.

llvm-svn: 140634

split landingpad instructions into a PHI node.
PR11016

llvm-svn: 140592

Disabling aggressive LSR saves compilation time, and with the new
indvars behavior usually improves performance.

llvm-svn: 140590

llvm-svn: 140583

The minor bug heuristic was noticed by inspection. I added the
isLoser/isValid helpers because they will become more
important with subsequent checkins.

llvm-svn: 140580

No test case. Noticed by inspection and I doubt it ever affects the
outcome of the overall heuristic, let alone final codegen.

llvm-svn: 140431

llvm-svn: 140327

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