This started as a small change, I swear.  Unfortunately, lots of things call the [I|F]CmpInst constructors.  Who knew!?

llvm-svn: 75200

llvm-svn: 75159

llvm-svn: 75040

This way ScalarEvolution can examine the loop to determine what state
it needs to update, if it chooses.

llvm-svn: 75029

llvm-svn: 75025

these instructions, no autoupgrade or backwards compatibility support is
provided.

llvm-svn: 74991

llvm-svn: 74985

llvm-svn: 74918

llvm-svn: 74878

Finish LLVMContext-ing lib/Analysis.  This required pushing LLVMContext's through the ValueTracking API.

llvm-svn: 74873

llvm-svn: 74844

llvm-svn: 74807

llvm-svn: 74781

llvm-svn: 74753

llvm-svn: 74748

This was considering vector intrinsics to have cost 2, but non-vector
intrinsics to have cost 1, which is backward.

llvm-svn: 74698

a key is present in a std::map or DenseMap to use find instead.

llvm-svn: 74676

PassManager was scheduling LCSSA before LoopSimplify, which does not
preserve LCSSA.

llvm-svn: 74661

llvm-svn: 74646

doesn't have an IV-based operand. This fixes PR4471.

llvm-svn: 74399

llvm-svn: 74395

inserted to replace that value must dominate all of of the basic
blocks associated with the uses of the value in the PHI, not just
one of them.

llvm-svn: 74376

This helps it avoid reusing an instruction that doesn't dominate all
of the users, in cases where the original instruction was inserted
before all of the users were known.  This may result in redundant
expansions of sub-expressions that depend on loop-unpredictable values
in some cases, however this isn't very common, and it primarily impacts
IndVarSimplify, so GVN can be expected to clean these up.

This eliminates the need for IndVarSimplify's FixUsesBeforeDefs,
which fixes several bugs.

llvm-svn: 74352

llvm-svn: 74330

llvm-svn: 74285

llvm-svn: 74243

llvm-svn: 74240

llvm-svn: 74146

terminator, instead of after the last phi. This fixes a bug
exposed by ScalarEvolution analyzing more kinds of loops.
This fixes PR4436.

llvm-svn: 74072

trip counts in more cases.

Generalize ScalarEvolution's isLoopGuardedByCond code to recognize
And and Or conditions, splitting the code out into an
isNecessaryCond helper function so that it can evaluate Ands and Ors
recursively, and make SCEVExpander be much more aggressive about
hoisting instructions out of loops.

test/CodeGen/X86/pr3495.ll has an additional instruction now, but
it appears to be due to an arbitrary register allocation difference.

llvm-svn: 74048

preheader is already an instruction.

llvm-svn: 74031

llvm-svn: 73910

llvm-svn: 73906

now, this hasn't mattered, because ScalarEvolution hasn't been able
to compute trip counts for loops with multiple exits. But it will
soon.

llvm-svn: 73864

terminology that LoopInfo uses.

llvm-svn: 73863

llvm-svn: 73796

hand-crafted testcase which demonstrates the bug that was exposed
in 254.gap.

llvm-svn: 73793

which it isn't prepared to handle.

llvm-svn: 73787

llvm-svn: 73783

as if they were multiple uses of the same instruction.  This interacts
well with the existing loadpre that j-t does to open up many new jump
threads earlier.

llvm-svn: 73768