ScalarEvolution::getAddExpr, which can be pretty expensive, when nothing
has changed, which is pretty common.

llvm-svn: 111042

before it rewrites the code, we need to use that in the post-rewrite pass.

llvm-svn: 110962

llvm-svn: 110489

llvm-svn: 110460

Also move 'default' case next to a real case to help compiler optimize in
non-Debug builds.
No functionality change.

llvm-svn: 110435

llvm-svn: 110410

ID member as the sole unique type identifier.  Clean up APIs related to this change.

llvm-svn: 110396

llvm-svn: 110384

Experiments show that we can safely increase our unrolling threshold without unduly impacting code size, particularly
since unrolling is not enabled at -Os.

llvm-svn: 110233

llvm-svn: 110223

llvm-svn: 110181

llvm-svn: 110113

Fixes potential ambiguity problems on VS 2010.

Patch by nobled!

llvm-svn: 110029

llvm-svn: 109886

llvm-svn: 109687

llvm-svn: 109581

llvm-svn: 109510

llvm-svn: 109509

llvm-svn: 109502

llvm-svn: 109424

dependence on DominanceFrontier. Instead, add an explicit DominanceFrontier
pass in StandardPasses.h to ensure that it gets scheduled at the right
time.

Declare that loop unrolling preserves ScalarEvolution, and shuffle some
getAnalysisUsages.

This eliminates one LoopSimplify and one LCCSA run in the standard
compile opts sequence.

llvm-svn: 109413

explicit inequality check.

llvm-svn: 109401

llvm-svn: 109400

llvm-svn: 109103

llvm-svn: 109092

llvm-svn: 109045

use getIncomingValueForBlock instead of
LoopInfo::getCanonicalInductionVariableIncrement.

llvm-svn: 108865

a redundant loopsimplify run from the default -O2 sequence.

llvm-svn: 108539

llvm-svn: 108522

different widths. In a use with a narrower fixup, formulae
may be wider than the fixup, in which case the high bits
aren't necessarily meaningful, so it isn't safe to reuse
them for uses with wider fixups.

This fixes PR7618, though the testcase is too large for a
reasonable regression test, since it heavily dependes on
hitting LSR's heuristics in a certain way.

llvm-svn: 108455

llvm-svn: 108453

a zero. This situation arrises in Fortran code with induction variables
that start at 1 instead of 0. This fixes PR7651.

llvm-svn: 108424

by a return that returns a constant, while elsewhere in the function
another return instruction returns a different constant.  This is a
special case of accumulator recursion, so just generalize the existing
logic a bit.

llvm-svn: 108241

llvm-svn: 108142

llvm-svn: 108138

llvm-svn: 108137

llvm-svn: 108135

llvm-svn: 108131

llvm-svn: 108130

the LHS and RHS of an and/or instruction, don't multiply add
known predecessor values.  This fixes the crash on testcase
from PR7498

llvm-svn: 108114