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

init.trampoline and adjust.trampoline intrinsics, into two intrinsics
like in GCC.  While having one combined intrinsic is tempting, it is
not natural because typically the trampoline initialization needs to
be done in one function, and the result of adjust trampoline is needed
in a different (nested) function.  To get around this llvm-gcc hacks the
nested function lowering code to insert an additional parent variable
holding the adjust.trampoline result that can be accessed from the child
function.  Dragonegg doesn't have the luxury of tweaking GCC code, so it
stored the result of adjust.trampoline in the memory GCC set aside for
the trampoline itself (this is always available in the child function),
and set up some new memory (using an alloca) to hold the trampoline.
Unfortunately this breaks Go which allocates trampoline memory on the
heap and wants to use it even after the parent has exited (!).  Rather
than doing even more hacks to get Go working, it seemed best to just use
two intrinsics like in GCC.  Patch mostly by Sanjoy Das.

llvm-svn: 139140

exception.

llvm-svn: 139117

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

llvm-svn: 138968

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

Resubmit with fix. Properly remove the instructions except for landingpad, which should be removed only when its invokes are.

llvm-svn: 138932

llvm-svn: 138931

The landingpad instruction can be removed only when its invokes are removed.

llvm-svn: 138930

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

Optimize chained bitcasts of the form A->B->A.
Undo r138722 and change isEliminableCastPair to allow this case.

llvm-svn: 138756

llvm-svn: 138722

llvm-svn: 138651

- 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

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

dominator information even though dominators were previously computed.

Patch by Nick Sumner.

llvm-svn: 138449

llvm-svn: 138243

llvm-svn: 138242

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

llvm-svn: 138153

llvm-svn: 138102

llvm-svn: 138025

C API functions must be able to see their extern "C" definitions, or it will be impossible to call them from C.

llvm-svn: 138022

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

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

llvm-svn: 138008

llvm-svn: 137985