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

llvm-svn: 184028

llvm-svn: 183960

I'll fix the heuristic in a general way in a follow-up commit.

llvm-svn: 180815

Fixes PR15838. Need to check for blocks with nothing but dbg.value.

I'm not sure how to force this situation with a unit test. I tried to
reduce the test case in PR15838 (1k lines of metadata) but gave up.

llvm-svn: 180227

For now, we just reschedule instructions that use the copied vregs and
let regalloc elliminate it. I would really like to eliminate the
copies on-the-fly during scheduling, but we need a complete
implementation of repairIntervalsInRange() first.

The general strategy is for the register coalescer to eliminate as
many global copies as possible and shrink live ranges to be
extended-basic-block local. The coalescer should not have to worry
about resolving local copies (e.g. it shouldn't attemp to reorder
instructions). The scheduler is a much better place to deal with local
interference. The coalescer side of this equation needs work.

llvm-svn: 180193

llvm-svn: 180191

llvm-svn: 179452

The register allocator expects minimal physreg live ranges. Schedule
physreg copies accordingly. This is slightly tricky when they occur in
the middle of the scheduling region. For now, this is handled by
rescheduling the copy when its associated instruction is
scheduled. Eventually we may instead bundle them, but only if we can
preserve the bundles as parallel copies during regalloc.

llvm-svn: 179449

llvm-svn: 178823

For now, just save the compile time since the ConvergingScheduler
heuristics don't use this analysis. We'll probably enable it later
after compile-time investigation.

llvm-svn: 178822

I'm getting more serious about tuning and enabling on x86/ARM. Start
by making the trace readable.

llvm-svn: 178821

llvm-svn: 177620

llvm-svn: 176787

This verifies live intervals both before and after scheduling. It's
useful for anyone hacking on live interval update.

Note that we don't yet pass verification all the time. We don't yet
handle updating nonallocatable live intervals perfectly.

llvm-svn: 176685

updateScheduledPressure method.

llvm-svn: 175362

llvm-svn: 175067

llvm-svn: 173775

llvm-svn: 173497

llvm-svn: 173433

llvm-svn: 173432

Allow the strategy to select SchedDFS. Allow the results of SchedDFS
to affect initialization of the scheduler state.

llvm-svn: 173425

interface and allow other strategies to select it.

llvm-svn: 173413

llvm-svn: 173318

llvm-svn: 172224

llvm-svn: 172223

This was an experimental option, but needs to be defined
per-target. e.g. PPC A2 needs to aggressively hide latency.

I converted some in-order scheduling tests to A2. Hal is working on
more test cases.

llvm-svn: 171946

llvm-svn: 170453

llvm-svn: 170452

llvm-svn: 170451

llvm-svn: 170450

llvm-svn: 170449

Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.

Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]

llvm-svn: 169131

Assertion failed: (TopRPTracker.getPos() == RegionBegin && "bad initial Top tracker").
rdar://12790302.

llvm-svn: 169072

assert (RemainingInstrs == 0 && "Instruction count mismatch!")

rdar://12776937.

llvm-svn: 169069