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

operation, but the way it's implemented requires the operation to also be
commutative.  So add a check for commutativity (and tweak the corresponding
comments).  This makes no difference in practice since every associative
LLVM instruction is also commutative!  Here's an example to show the need
for commutativity: the accum_recursion.ll testcase calculates the factorial
function.  Before the transformation the result of a call is
  ((((1*1)*2)*3)...)*x
while afterwards it is
  (((1*x)*(x-1))...*2)*1
which clearly requires both associativity and commutativity of * to be equal
to the original.

llvm-svn: 108056

llvm-svn: 107976

llvm-svn: 107971

llvm-svn: 107969