I'm sure it is harmless.  Original commit message:
If PrototypeValue is erased in the middle of using the SSAUpdator
then the SSAUpdator may access freed memory.  Instead, simply pass
in the type and name explicitly, which is all that was used anyway.

llvm-svn: 112810

llvm-svn: 112763

infinite loops or exits will eventually exit. This fixes PR5373.

llvm-svn: 112745

if we schedule another LVI-using pass afterwards.

llvm-svn: 112722

self host errors on clang-x86-64.

llvm-svn: 112719

then the SSAUpdator may access freed memory.  Instead, simply pass
in the type and name explicitly, which is all that was used anyway.

llvm-svn: 112699

on llvmdev: SRoA is introducing MMX datatypes like <1 x i64>,
which then cause random problems because the X86 backend is
producing mmx stuff without inserting proper emms calls.

In the short term, force off MMX datatypes.  In the long term,
the X86 backend should not select generic vector types to MMX
registers.  This is being worked on, but won't be done in time
for 2.8.  rdar://8380055

llvm-svn: 112696

by 112440 are resolved.

llvm-svn: 112692

instead of hoisting them, just fold them away.  This occurs in the
testcase for PR8041, for example.

llvm-svn: 112669

llvm-svn: 112643

More cleanups of my JumpThreading transforms, including extracting some duplicated code into a helper function.

llvm-svn: 112634

llvm-svn: 112628

llvm-svn: 112625

llvm-svn: 112620

Don't perform an extra traversal of the function just to do cleanup.  We can safely simplify instructions after each block has been processed without worrying about iterator invalidation.

llvm-svn: 112594

llvm-svn: 112591

llvm-svn: 112590

More Chris-inspired JumpThreading fixes: use ConstantExpr to correctly constant-fold undef, and be more careful with its return value.
This actually exposed an infinite recursion bug in ComputeValueKnownInPredecessors which theoretically already existed (in JumpThreading's
handling of and/or of i1's), but never manifested before.  This patch adds a tracking set to prevent this case.

llvm-svn: 112589

llvm-svn: 112560

llvm-svn: 112553

Re-apply r112539, being more careful to respect the return values of the constant folding methods.  Additionally,
use the ConstantExpr::get*() methods to simplify some constant folding.

llvm-svn: 112550

llvm-svn: 112545

llvm-svn: 112543

Fixes and cleanups pointed out by Chris.  In general, be careful to handle 0 results from ComputeValueKnownInPredecessors
(indicating undef), and re-use existing constant folding APIs.

llvm-svn: 112539

instead of PromoteMemToReg.  This allows it to stop using DF and DT,
eliminating a computation of DT and DF from clang -O3.  Clang is now
down to 2 runs of DomFrontier.

llvm-svn: 112457

assertingvh so we get a violent explosion if the pointer dangles.

2) Fix AliasSetTracker::deleteValue to remove call sites with
   by-pointer comparisons instead of by-alias queries.  Using
   findAliasSetForCallSite can cause alias sets to get merged
   when they shouldn't, and can also miss alias sets when the
   call is readonly.

#2 fixes PR6889, which only repros with a .c file :(

llvm-svn: 112452

out of loops, just delete them.

llvm-svn: 112451

symtab manipulation, so its faster (in addition to being
more elegant)

llvm-svn: 112450

llvm-svn: 112449

of AST to remove the hoisted instruction from the AST, since it
is no longer in the loop.

llvm-svn: 112448

LICM correctly.  When sinking an instruction, it should not add
entries for the sunk instruction to the AST, it should remove
the entry for the sunk instruction.  The blocks being sunk to
are not in the loop, so their instructions shouldn't be in the
AST (yet)!

llvm-svn: 112447

keeping them around until the pass is destroyed, keep them
around a) just when useful (not for outer loops) and b) destroy
them right after we use them.  This should reduce memory use
and fixes potential bugs where a loop is deleted and another
loop gets allocated to the same address.

llvm-svn: 112446

claims that it preserves domfrontier if it doesn't really.

llvm-svn: 112445

for the unroller to pretend it supports updating it.  It still
has a horrible hack for DomTree.

llvm-svn: 112444

other filtering techniques, as those may allow it to filter
out more obviously unprofitable candidates.

llvm-svn: 112441

LSRInstance data structures up to date. This fixes some
pessimizations caused by stale data which will be exposed
in an upcoming change.

llvm-svn: 112440

NarrowSearchSpaceUsingHeuristics into separate functions.

llvm-svn: 112439

llvm-svn: 112438

llvm-svn: 112437

the high-level logic.

llvm-svn: 112436