summaryrefslogtreecommitdiff
path: root/lib/Target/ARM/ARMScheduleA8.td
diff options
context:
space:
mode:
authorAndrew Trick <atrick@apple.com>2012-07-07 04:00:00 +0000
committerAndrew Trick <atrick@apple.com>2012-07-07 04:00:00 +0000
commit2661b411ccc81b1fe19194d3f43b2630cbef3f28 (patch)
tree0decaebaee6c3a1a9d42df6b5619de1ffb2fac7d /lib/Target/ARM/ARMScheduleA8.td
parent06495cd7f2a91c4f659eac5e55b1c08b014d0a08 (diff)
downloadllvm-2661b411ccc81b1fe19194d3f43b2630cbef3f28.tar.gz
llvm-2661b411ccc81b1fe19194d3f43b2630cbef3f28.tar.bz2
llvm-2661b411ccc81b1fe19194d3f43b2630cbef3f28.tar.xz
I'm introducing a new machine model to simultaneously allow simple
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159891 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'lib/Target/ARM/ARMScheduleA8.td')
-rw-r--r--lib/Target/ARM/ARMScheduleA8.td21
1 files changed, 16 insertions, 5 deletions
diff --git a/lib/Target/ARM/ARMScheduleA8.td b/lib/Target/ARM/ARMScheduleA8.td
index 61de00a208..56197d4e00 100644
--- a/lib/Target/ARM/ARMScheduleA8.td
+++ b/lib/Target/ARM/ARMScheduleA8.td
@@ -22,11 +22,7 @@ def A8_NLSPipe : FuncUnit; // NEON LS pipe
//
// Dual issue pipeline represented by A8_Pipe0 | A8_Pipe1
//
-def CortexA8Itineraries : MultiIssueItineraries<
- 2, // IssueWidth
- -1, // MinLatency - OperandCycles are interpreted as MinLatency.
- 2, // LoadLatency - overriden by OperandCycles.
- 10, // HighLatency - currently unused.
+def CortexA8Itineraries : ProcessorItineraries<
[A8_Pipe0, A8_Pipe1, A8_LSPipe, A8_NPipe, A8_NLSPipe],
[], [
// Two fully-pipelined integer ALU pipelines
@@ -1061,3 +1057,18 @@ def CortexA8Itineraries : MultiIssueItineraries<
InstrStage<1, [A8_NPipe], 0>,
InstrStage<2, [A8_NLSPipe]>], [4, 1, 2, 2, 3, 3, 1]>
]>;
+
+// ===---------------------------------------------------------------------===//
+// This following definitions describe the simple machine model which
+// will replace itineraries.
+
+// Cortex-A8 machine model for scheduling and other instruction cost heuristics.
+def CortexA8Model : SchedMachineModel {
+ let IssueWidth = 2; // 2 micro-ops are dispatched per cycle.
+ let MinLatency = -1; // OperandCycles are interpreted as MinLatency.
+ let LoadLatency = 2; // Optimistic load latency assuming bypass.
+ // This is overriden by OperandCycles if the
+ // Itineraries are queried instead.
+
+ let Itineraries = CortexA8Itineraries;
+}