one user. This code will be restructured soon and FormulaSorter
is getting in the way.

llvm-svn: 116012

llvm-svn: 116011

not just base registers.

llvm-svn: 116010

llvm-svn: 116009

the old use to the new one.

llvm-svn: 116008

This doesn't usually matter, because the other heuristics usually
succeed regardless, but it's good to keep the register use
bookkeeping consistent.

llvm-svn: 116005

llvm-svn: 115996

llvm-svn: 114841

llvm-svn: 114278

by 112440 are resolved.

llvm-svn: 112692

other filtering techniques, as those may allow it to filter
out more obviously unprofitable candidates.

llvm-svn: 112441

LSRInstance data structures up to date. This fixes some
pessimizations caused by stale data which will be exposed
in an upcoming change.

llvm-svn: 112440

NarrowSearchSpaceUsingHeuristics into separate functions.

llvm-svn: 112439

llvm-svn: 112438

llvm-svn: 112437

the high-level logic.

llvm-svn: 112436

llvm-svn: 112435

llvm-svn: 112434

of the two.

llvm-svn: 111495

uninteresting, just put all the operands on one list and make
GenerateReassociations make the decision about what's interesting.
This is simpler, and it avoids an extra ScalarEvolution::getAddExpr call.

llvm-svn: 111133

This isn't necessary, because ScalarEvolution sorts them anyway,
but it's tidier this way.

llvm-svn: 111132

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

llvm-svn: 111042

llvm-svn: 110460

llvm-svn: 110410

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

llvm-svn: 110396

llvm-svn: 110223

Fixes potential ambiguity problems on VS 2010.

Patch by nobled!

llvm-svn: 110029

llvm-svn: 109045

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

llvm-svn: 107270

SCEVUnknown values which are loop-variant, as LSR can't do anything
interesting with these values in any case. This fixes very slow compile
times on loops which have large numbers of such values.

llvm-svn: 106897

llvm-svn: 106764

enough special case, and it theoretically allows more folding because
it works even when x is unanalyzable.

llvm-svn: 106763

llvm-svn: 106759

is another max which folds. This fixes PR7454.

llvm-svn: 106594

SmallVector, and other SmallVector simplifications.

llvm-svn: 106452

llvm-svn: 106397

use sharing map. The reconcileNewOffset logic already forces a
separate use if the kinds differ, so incorporating the kind in the
key means we can track more sharing opportunities.

More sharing means fewer total uses to track, which means smaller
problem sizes, which means the conservative throttles don't kick
in as often.

llvm-svn: 106396