| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
perform initialization without static constructors AND without explicit initialization
by the client. For the moment, passes are required to initialize both their
(potential) dependencies and any passes they preserve. I hope to be able to relax
the latter requirement in the future.
llvm-svn: 116334
|
|
|
|
| |
llvm-svn: 115996
|
|
|
|
| |
llvm-svn: 115053
|
|
|
|
|
|
|
|
|
|
|
| |
tends to cause high
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
|
|
|
|
|
|
|
|
| |
a sweet spot in the performance per
code size increase curve.
llvm-svn: 113595
|
|
|
|
|
|
|
|
|
|
|
| |
with calls, is
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
|
|
|
|
|
|
|
|
| |
cannot be unrolled. After some discussion,
there seems to be a better way to achieve the same effect.
llvm-svn: 113528
|
|
|
|
|
|
| |
Revert it.
llvm-svn: 113527
|
|
|
|
| |
llvm-svn: 113526
|
|
|
|
|
|
|
|
| |
when we unroll a loop.
Next step is to recalculate the threshold values given this new heuristic.
llvm-svn: 113525
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
optimized for size.
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
|
|
|
|
|
|
|
|
| |
address of the static
ID member as the sole unique type identifier. Clean up APIs related to this change.
llvm-svn: 110396
|
|
|
|
|
|
|
|
| |
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
|