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

address spaces when SRoA'ing memcpy's.

llvm-svn: 107846

llvm-svn: 107637

have any effect, and second, deleting stores can potentially invalidate
an AliasAnalysis, and there's currently no notification for this.

llvm-svn: 107496

llvm-svn: 107278

llvm-svn: 107273

llvm-svn: 107272

llvm-svn: 107271

llvm-svn: 107270

llvm-svn: 107015

llvm-svn: 107000

large integers, the first inserted value would always create
an 'or X, 0'.  Even though this is trivially zapped by
instcombine, don't bother creating this pointless instruction.

llvm-svn: 106979

the returned value after the tail call if it differs from other return
values.  The optimal thing to do would be to introduce a phi node for
the return value, but for the moment just fix the miscompile.

llvm-svn: 106947