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

llvm-svn: 141058

but not load instructions. Noticed by inspection.

llvm-svn: 140966

Clean up uses of switch instructions so they are not dependent on the operand ordering.  Patch by Stepan Dyatkovskiy.

llvm-svn: 140803

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

Some passes require breaking critical edges before they're called. Don't
segfault because of that.

llvm-svn: 140196

llvm-svn: 140172

llvm-svn: 140168

llvm-svn: 140164

llvm-svn: 140094

extract the landing pad block. Otherwise, there will be a situation where the
invoke's unwind edge lands on a non-landing pad.

We also forbid the user from extracting the landing pad block by itself. Again,
this is not a valid transformation.

llvm-svn: 140083

llvm-svn: 140026

exception.

llvm-svn: 139117

- Reword comments.
- Allow undefined behavior interfering with undefined behavior.
- Add address space checks.

llvm-svn: 138619

SimplifyCFG: If we have a PHI node that can evaluate to NULL and do a load or store to the address returned by the PHI node then we can consider this incoming value as dead and remove the edge pointing there, unless there are instructions that can affect control flow executed in between.

In theory this could be extended to other instructions, eg. division by zero, but it's likely that it will "miscompile" some code because people depend on div by zero not trapping. NULL pointer dereference usually leads to a crash so we should be on the safe side.

This shrinks the size of a Release clang by 16k on x86_64.

llvm-svn: 138618

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

llvm-svn: 138537

dominator information even though dominators were previously computed.

Patch by Nick Sumner.

llvm-svn: 138449

then don't split it a second time, since that block will be dead.

llvm-svn: 138153

We have to be careful when splitting the landing pad block, because the
landingpad instruction is required to remain as the first non-PHI of an invoke's
unwind edge. To retain this, we split the block into two blocks, moving the
predecessors within the loop to one block and the remaining predecessors to the
other. The landingpad instruction is cloned into the new blocks.

llvm-svn: 138015

SplitLandingPadPredecessors is similar to SplitBlockPredecessors in that it
splits the current block and attaches a set of predecessors to the new basic
block. However, it differs from SplitBlockPredecessors in that it's specifically
designed to handle landing pad blocks.

Two new basic blocks are created: one that is has the vector of predecessors as
its predecessors and one that has the remaining predecessors as its
predecessors. Those two new blocks then receive a cloned copy of the landingpad
instruction from the original block. The landingpad instructions are joined in a
PHI, etc. Like SplitBlockPredecessors, it updates the LLVM IR, AliasAnalysis,
DominatorTree, DominanceFrontier, LoopInfo, and LCCSA analyses.

llvm-svn: 138014

aren't from an indirect branch need to be dominated by the loop header.

llvm-svn: 137981

function.

llvm-svn: 137979

llvm-svn: 137978

llvm-svn: 137959

functionality change.

llvm-svn: 137926

llvm-svn: 137872

One way to exit the loop is through an unwind edge. However, that may involve
splitting the critical edge of the landing pad, which is non-trivial. Prevent
the transformation from rewriting the landing pad exit loop block.

llvm-svn: 137871

so requires more care than this generic algorithm should handle.

llvm-svn: 137866

llvm-svn: 137743

to be wrong (or at least somewhat suspect).  Leave a FIXME for Bill.

llvm-svn: 137694

llvm-svn: 137693

This commit includes a mention of the landingpad instruction, but it's not
changing the behavior around it.  I think the current behavior is correct,
though.  Bill, can you double-check that?

llvm-svn: 137691

llvm-svn: 137690

llvm-svn: 137654

llvm-svn: 137642

This builds off of the current scheme, but instead of llvm.eh.exception and
llvm.eh.selector, it uses the landingpad instruction. And instead of
llvm.eh.resume, it uses the resume instruction.

Because of the invariants in the landing pad instruction, a lot of code that's
currently needed to find the appropriate intrinsic calls for an invoke
instruction won't be needed once we go to the new EH scheme. The "FIXME"s tell
us what to remove after we switch.

llvm-svn: 137576

llvm-svn: 137480

when building with assertions disabled.

llvm-svn: 137460

Distinguish between two copies of one inlined variable. Take 2.

llvm-svn: 137253

Also, my apologies for spoiling the autocomplete on SimplifyInstructions.cpp. I couldn't think of a better filename.

llvm-svn: 137229