| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
This makes the API a bit more natural to use and makes it easier to make
LiveRanges implementation details private.
llvm-svn: 192394
|
|
|
|
| |
llvm-svn: 191312
|
|
|
|
|
|
|
|
|
|
|
| |
interface.
The global registry is used to allow command line override of the
scheduler selection, but does not work well as the normal selection
API. For example, the same LLVM process should be able to target
multiple targets or subtargets.
llvm-svn: 191071
|
|
|
|
|
|
|
|
|
|
| |
This was an experimental scheduler a year ago. It's now used by
several subtargets, both in-order and out-of-order, and it
is about to be enabled by default for x86 and armv7. It will be the
new GenericScheduler for subtargets that don't provide their own
SchedulingStrategy.
llvm-svn: 191051
|
|
|
|
| |
llvm-svn: 190367
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Arnold's idea.
I generally try to avoid stateful heuristics because it can make
debugging harder. However, we need a way to prevent the latency
priority from dominating, and it somewhat makes sense to schedule
aggressively for latency only within an issue group.
Swift in particular likes this, and it doesn't hurt anyone else:
| Benchmarks/MiBench/consumer-lame | 10.39% |
| Benchmarks/Misc/himenobmtxpa | 9.63% |
llvm-svn: 190360
|
|
|
|
| |
llvm-svn: 190181
|
|
|
|
| |
llvm-svn: 190180
|
|
|
|
| |
llvm-svn: 190179
|
|
|
|
| |
llvm-svn: 190178
|
|
|
|
|
|
| |
The latency based scheduling could induce spills in some cases.
llvm-svn: 190177
|
|
|
|
|
|
|
|
| |
Allow subtargets to customize the generic scheduling strategy.
This is convenient for targets that don't need to add new heuristics
by specializing the strategy.
llvm-svn: 190176
|
|
|
|
|
|
|
|
|
| |
Fast register pressure tracking currently only takes effect during
bottom up scheduling. Forcing this is a bit faster and simpler for
targets that don't have many scheduling constraints and don't need
top-down scheduling.
llvm-svn: 190014
|
|
|
|
| |
llvm-svn: 189997
|
|
|
|
| |
llvm-svn: 189995
|
|
|
|
| |
llvm-svn: 189994
|
|
|
|
| |
llvm-svn: 189993
|
|
|
|
| |
llvm-svn: 189992
|
|
|
|
|
|
|
|
|
|
| |
too small.
If the instruction window is < NumRegs/2, pressure tracking is not
likely to be effective. The scheduler has to process a very large
number of tiny blocks. We want this to be fast.
llvm-svn: 189991
|
|
|
|
| |
llvm-svn: 189990
|
|
|
|
| |
llvm-svn: 189989
|
|
|
|
| |
llvm-svn: 189988
|
|
|
|
|
|
|
|
| |
Register pressure tracking is half the complexity of the
scheduler. It's useful to be able to turn it off for compile time and
performance comparisons.
llvm-svn: 189987
|
|
|
|
|
|
|
|
| |
There was one case that we could hit a DebugValue where I didn't think
to check. DebugValues are evil. No checkinable test case, sorry. It's
an obvious fix.
llvm-svn: 189717
|
|
|
|
|
|
|
| |
This removes all expensive pressure tracking logic from the scheduling
critical path of node comparison.
llvm-svn: 189643
|
|
|
|
|
|
|
| |
Only compare pressure within the same set. When multiple sets are
affected, we prioritize the most constrained set.
llvm-svn: 189641
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
liveness later.
Created SUPressureDiffs array to hold the per node PDiff computed during DAG building.
Added a getUpwardPressureDelta API that will soon replace the old
one. Compute PressureDelta here from the precomputed PressureDiffs.
Updating for liveness will come next.
llvm-svn: 189640
|
|
|
|
| |
llvm-svn: 189635
|
|
|
|
|
|
| |
This should be much more clear now. It's still disabled pending testing.
llvm-svn: 189597
|
|
|
|
|
|
|
|
|
|
|
| |
Estimate the cyclic critical path within a single block loop. If the
acyclic critical path is longer, then the loop will exhaust OOO
resources after some number of iterations. If lag between the acyclic
critical path and cyclic critical path is longer the the time it takes
to issue those loop iterations, then aggressively schedule for
latency.
llvm-svn: 189120
|
|
|
|
|
|
|
|
|
| |
count.
This fixes a pathological compile time problem with very large blocks
and lots of scheduling boundaries.
llvm-svn: 189116
|
|
|
|
| |
llvm-svn: 187895
|
|
|
|
|
|
|
|
|
|
|
| |
When registers must be live throughout the scheduling region, increase
the limit for the register class. Once we exceed the original limit,
they will be spilled, and there's no point further reducing pressure.
This isn't a perfect heuristics but avoids a situation where the
scheduler could become trapped by trying to achieve the impossible.
llvm-svn: 187436
|
|
|
|
| |
llvm-svn: 187435
|
|
|
|
|
|
| |
Consider which set is being increased or decreased before comparing.
llvm-svn: 187110
|
|
|
|
| |
llvm-svn: 187107
|
|
|
|
|
|
| |
parameter of ConvergingScheduler::SchedBoundary::getOtherResourceCount
llvm-svn: 186658
|
|
|
|
|
|
| |
make more sense.
llvm-svn: 186632
|
|
|
|
| |
llvm-svn: 184565
|
|
|
|
| |
llvm-svn: 184564
|
|
|
|
| |
llvm-svn: 184133
|
|
|
|
|
|
| |
A complex, expensive heuristic with little value in the current design.
llvm-svn: 184132
|
|
|
|
| |
llvm-svn: 184130
|
|
|
|
|
|
|
|
| |
This eliminates the MultiPressure scheduling "reason". It was
sensitive to queue order. We don't like being sensitive to queue
order.
llvm-svn: 184129
|
|
|
|
| |
llvm-svn: 184039
|
|
|
|
| |
llvm-svn: 184038
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace the ill-defined MinLatency and ILPWindow properties with
with straightforward buffer sizes:
MCSchedMode::MicroOpBufferSize
MCProcResourceDesc::BufferSize
These can be used to more precisely model instruction execution if desired.
Disabled some misched tests temporarily. They'll be reenabled in a few commits.
llvm-svn: 184032
|
|
|
|
|
|
|
| |
"Counts" refer to scaled resource counts within a region. CurrMOps is
simply the number of micro-ops to be issue in the current cycle.
llvm-svn: 184031
|
|
|
|
| |
llvm-svn: 184030
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Heuristics compare the critical path in the scheduled code, called
ExpectedLatency, with the latency of instructions remaining to be
scheduled. There are two ways to look at remaining latency:
(1) Dependent latency includes the latency between unscheduled and
scheduled instructions.
(2) Independent latency is simply the height (bottom-up) or depth
(top-down) of instructions currently in the ready Q.
llvm-svn: 184029
|