llvm-svn: 115996

llvm-svn: 115053

register pressure and thus excess spills, which we don't currently recover from well.  This should
be re-evaluated in the future if our ability to generate good spills/splits improves.

Partial fix for <rdar://problem/7635585>.

llvm-svn: 114919

Lower the unrolling theshold to 150.  Empirical tests indicate that this is a sweet spot in the performance per
code size increase curve.

llvm-svn: 113595

not unrolling loops that contain calls that would be better off getting inlined.  This mostly
comes up when an interleaved devirtualization pass has devirtualized a call which the inliner
will inline on a future pass.  Thus, rather than blocking all loops containing calls, add
a metric for "inline candidate calls" and block loops containing those instead.

llvm-svn: 113535

Revert r113439, which relaxed the requirement that loops containing calls cannot be unrolled.  After some discussion,
there seems to be a better way to achieve the same effect.

llvm-svn: 113528

llvm-svn: 113527

llvm-svn: 113526

Next step is to recalculate the threshold values given this new heuristic.

llvm-svn: 113525

Relax the "don't unroll loops containing calls" rule.  Instead, when a loop contains a call, lower the
unrolling threshold to the optimize-for-size threshold.  Basically, for loops containing calls, unrolling
can still be profitable as long as the loop is REALLY small.

llvm-svn: 113439

The threshold value of 50 is arbitrary, and I chose it simply by analogy to the inlining thresholds, where
the baseline unrolling threshold is slightly smaller than the baseline inlining threshold.  This could
undoubtedly use some tuning.

llvm-svn: 113306

for the unroller to pretend it supports updating it.  It still
has a horrible hack for DomTree.

llvm-svn: 112444

llvm-svn: 110460

llvm-svn: 110410

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

llvm-svn: 110396

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

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

llvm-svn: 109045

compute a set of reachable blocks for itself each time it is called, which
is fairly frequently.

llvm-svn: 98179

llvm-svn: 95454

llvm-svn: 92623

the new common CodeMetrics code.

llvm-svn: 85663

llvm-svn: 85661

LoopUnrollPass.cpp, for consistency with other passes which are
similarly split.

llvm-svn: 85659

llvm-svn: 80766

llvm-svn: 78889

No intended functionality change.

llvm-svn: 78888

llvm-svn: 78887

llvm-svn: 78886

llvm-svn: 77271

 - Some clients which used DOUT have moved to DEBUG. We are deprecating the
   "magic" DOUT behavior which avoided calling printing functions when the
   statement was disabled. In addition to being unnecessary magic, it had the
   downside of leaving code in -Asserts builds, and of hiding potentially
   unnecessary computations.

llvm-svn: 77019

GEP's don't usually become instructions.

llvm-svn: 69631

llvm-svn: 63198

LoopPass*.
 - Although less precise, this means they can be used in clients
   without RTTI (who would otherwise need to include LoopPass.h, which
   eventually includes things using dynamic_cast). This was the
   simplest solution that presented itself, but I am happy to use a
   better one if available.

llvm-svn: 58010

llvm-svn: 55779

partially unroll a loop when fully unrolling would not fit under the threshold.

Patch by Mikael Lepistö.

llvm-svn: 54160

llvm-svn: 53089

llvm-svn: 52616

included after local headers.

llvm-svn: 51187

compiling with gcc 4.3.

llvm-svn: 51145