Loop::hasLoopInvariantOperands method. Remove
a useless and confusing Loop::isLoopInvariant(Instruction)
method, which didn't do what you thought it did.

No functionality change.

llvm-svn: 113133

llvm-svn: 113115

llvm-svn: 113114

llvm-svn: 113113

llvm-svn: 113106

This reduces malloc traffic (yay!) and removes MergeFunctionsEqualityInfo.

llvm-svn: 113105

strong functions first to make sure they're the canonical definitions and then
do a second pass looking only for weak functions.

llvm-svn: 113104

llvm-svn: 113073

into an inner loop, as the new loop iteration may differ substantially.
This fixes PR8078.

llvm-svn: 113057

location is being re-stored to the memory location.  We would get
a dangling pointer from the SSAUpdate data structure and miss a 
use.  This fixes PR8068

llvm-svn: 113042

llvm-svn: 113025

is provable that they're equivalent.  This fixes PR4855.

llvm-svn: 112994

llvm-svn: 112878

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

two are weak, we make them thunks to a new strong function) so don't iterate
through the function list as we're modifying it.

Also add back the outermost loop which got removed during the cleanups.

llvm-svn: 112595

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

where we hash, compare and fold, instead of one iteration where we build up
the hash buckets and a second one to fold.

llvm-svn: 112582

Remove r111665, which implemented store-narrowing in InstCombine.  Chris discovered a miscompilation in it, and it's not easily
fixable at the optimizer level. I'll investigate reimplementing it in DAGCombine.

llvm-svn: 112575

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