llvm-svn: 160621

subtarget CPU descriptions and support new features of
MachineScheduler.

MachineModel has three categories of data:
1) Basic properties for coarse grained instruction cost model.
2) Scheduler Read/Write resources for simple per-opcode and operand cost model (TBD).
3) Instruction itineraties for detailed per-cycle reservation tables.

These will all live side-by-side. Any subtarget can use any
combination of them. Instruction itineraries will not change in the
near term. In the long run, I expect them to only be relevant for
in-order VLIW machines that have complex contraints and require a
precise scheduling/bundling model. Once itineraries are only actively
used by VLIW-ish targets, they could be replaced by something more
appropriate for those targets.

This tablegen backend rewrite sets things up for introducing
MachineModel type #2: per opcode/operand cost model.

llvm-svn: 159891

llvm-svn: 159599

llvm-svn: 159408

llvm-svn: 159407

llvm-svn: 158608

Allow targets to access this API. It's required for RegisterPressure.

llvm-svn: 158102

Make it a general utility for use by Targets.

llvm-svn: 158097

Minimum latency determines per-cycle scheduling groups.
Expected latency determines critical path and cost.

llvm-svn: 158021

llvm-svn: 157975

llvm-svn: 157455

llvm-svn: 157438

(except the part about choosing direction)

llvm-svn: 157437

llvm-svn: 157429

llvm-svn: 157428

The Hazard checker implements in-order contraints, or interlocked
resources. Ready instructions with hazards do not enter the available
queue and are not visible to other heuristics.

The major code change is the addition of SchedBoundary to encapsulate
the state at the top or bottom of the schedule, including both a
pending and available queue.

The scheduler now counts cycles in sync with the hazard checker. These
are minimum cycle counts based on known hazards.

Targets with no itinerary (x86_64) currently remain at cycle 0. To fix
this, we need to provide some maximum issue width for all targets. We
also need to add the concept of expected latency vs. minimum latency.

llvm-svn: 157427

llvm-svn: 157426

llvm-svn: 157425

llvm-svn: 157424

llvm-svn: 157020

llvm-svn: 157007

Introduce the basic strategy for register pressure scheduling.

1) Respect target limits at all times.

2) Indentify critical register classes (pressure sets).
   Track pressure within the scheduled region.
   Avoid increasing scheduled pressure for critical registers.

3) Avoid exceeding the max pressure of the region prior to scheduling.

Added logic for picking between the top and bottom ready Q's based on
regpressure heuristics.

Status: functional but needs to be asjusted to achieve good results.
llvm-svn: 157006

llvm-svn: 157005

llvm-svn: 157003

llvm-svn: 156576

llvm-svn: 156575

Prioritize the instruction that comes closest to keeping pressure
under the target's limit. Then prioritize instructions that avoid
increasing the max pressure in the scheduled region. The max pressure
heuristic is a tad aggressive. Later I'll fix it to consider the
unscheduled pressure as well.

WIP: This is mostly functional but untested and not likely to do much good yet.
llvm-svn: 156574

llvm-svn: 156573

llvm-svn: 156572

llvm-svn: 156571

llvm-svn: 155486

llvm-svn: 155458

llvm-svn: 155457

The DAG builder is a convenient place to do it. Hopefully this is more
efficient than a separate traversal over the same region.

llvm-svn: 155456

llvm-svn: 153827

llvm-svn: 153161

llvm-svn: 153160

llvm-svn: 153159

instructions have been scheduled. Handy for tracking down scheduler bugs, or
bugs exposed by scheduling.

llvm-svn: 153045

llvm-svn: 152711