maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/lib/Target/PowerPC/PPCSchedule440.td

609 lines
35 KiB
TableGen
Raw Normal View History

Emacs-tag and some comment fix for all ARM, CellSPU, Hexagon, MBlaze, MSP430, PPC, PTX, Sparc, X86, XCore. llvm-svn: 150878
2012-02-18 20:03:15 +08:00
//===-- PPCSchedule440.td - PPC 440 Scheduling Definitions -*- tablegen -*-===//
//
Add PPC 440 scheduler and some associated tests (new files) llvm-svn: 142171
2011-10-17 12:03:55 +08:00
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
Emacs-tag and some comment fix for all ARM, CellSPU, Hexagon, MBlaze, MSP430, PPC, PTX, Sparc, X86, XCore. llvm-svn: 150878
2012-02-18 20:03:15 +08:00
//
Add PPC 440 scheduler and some associated tests (new files) llvm-svn: 142171
2011-10-17 12:03:55 +08:00
//===----------------------------------------------------------------------===//
// Primary reference:
Remove >80-col line and unicode llvm-svn: 142209
2011-10-18 02:10:08 +08:00
// PowerPC 440x6 Embedded Processor Core User's Manual.
Add PPC 440 scheduler and some associated tests (new files) llvm-svn: 142171
2011-10-17 12:03:55 +08:00
// IBM (as updated in) 2010.
// The basic PPC 440 does not include a floating-point unit; the pipeline
// timings here are constructed to match the FP2 unit shipped with the
// PPC-440- and PPC-450-based Blue Gene (L and P) supercomputers.
// References:
// S. Chatterjee, et al. Design and exploitation of a high-performance
// SIMD floating-point unit for Blue Gene/L.
// IBM J. Res. & Dev. 49 (2/3) March/May 2005.
// also:
// Carlos Sosa and Brant Knudson. IBM System Blue Gene Solution:
// Blue Gene/P Application Development.
// IBM (as updated in) 2009.
//===----------------------------------------------------------------------===//
// Functional units on the PowerPC 440/450 chip sets
//
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
def P440_DISS1 : FuncUnit; // Issue unit 1
def P440_DISS2 : FuncUnit; // Issue unit 2
def P440_LRACC : FuncUnit; // Register access and dispatch for
// the simple integer (J-pipe) and
// load/store (L-pipe) pipelines
def P440_IRACC : FuncUnit; // Register access and dispatch for
// the complex integer (I-pipe) pipeline
def P440_FRACC : FuncUnit; // Register access and dispatch for
// the floating-point execution (F-pipe) pipeline
def P440_IEXE1 : FuncUnit; // Execution stage 1 for the I pipeline
def P440_IEXE2 : FuncUnit; // Execution stage 2 for the I pipeline
def P440_IWB : FuncUnit; // Write-back unit for the I pipeline
def P440_JEXE1 : FuncUnit; // Execution stage 1 for the J pipeline
def P440_JEXE2 : FuncUnit; // Execution stage 2 for the J pipeline
def P440_JWB : FuncUnit; // Write-back unit for the J pipeline
def P440_AGEN : FuncUnit; // Address generation for the L pipeline
def P440_CRD : FuncUnit; // D-cache access for the L pipeline
def P440_LWB : FuncUnit; // Write-back unit for the L pipeline
def P440_FEXE1 : FuncUnit; // Execution stage 1 for the F pipeline
def P440_FEXE2 : FuncUnit; // Execution stage 2 for the F pipeline
def P440_FEXE3 : FuncUnit; // Execution stage 3 for the F pipeline
def P440_FEXE4 : FuncUnit; // Execution stage 4 for the F pipeline
def P440_FEXE5 : FuncUnit; // Execution stage 5 for the F pipeline
def P440_FEXE6 : FuncUnit; // Execution stage 6 for the F pipeline
def P440_FWB : FuncUnit; // Write-back unit for the F pipeline
Add PPC 440 scheduler and some associated tests (new files) llvm-svn: 142171
2011-10-17 12:03:55 +08:00
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
def P440_LWARX_Hold : FuncUnit; // This is a pseudo-unit which is used
// to make sure that no lwarx/stwcx.
// instructions are issued while another
// lwarx/stwcx. is in the L pipe.
Add PPC 440 scheduler and some associated tests (new files) llvm-svn: 142171
2011-10-17 12:03:55 +08:00
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
def P440_GPR_Bypass : Bypass; // The bypass for general-purpose regs.
def P440_FPR_Bypass : Bypass; // The bypass for floating-point regs.
Add PPC 440 scheduler and some associated tests (new files) llvm-svn: 142171
2011-10-17 12:03:55 +08:00
// Notes:
// Instructions are held in the FRACC, LRACC and IRACC pipeline
// stages until their source operands become ready. Exceptions:
// - Store instructions will hold in the AGEN stage
// - The integer multiply-accumulate instruction will hold in
// the IEXE1 stage
//
// For most I-pipe operations, the result is available at the end of
// the IEXE1 stage. Operations such as multiply and divide must
// continue to execute in IEXE2 and IWB. Divide resides in IWB for
// 33 cycles (multiply also calculates its result in IWB). For all
// J-pipe instructions, the result is available
// at the end of the JEXE1 stage. Loads have a 3-cycle latency
// (data is not available until after the LWB stage).
//
// The L1 cache hit latency is four cycles for floating point loads
// and three cycles for integer loads.
//
// The stwcx. instruction requires both the LRACC and the IRACC
// dispatch stages. It must be issued from DISS0.
//
// All lwarx/stwcx. instructions hold in LRACC if another
// uncommitted lwarx/stwcx. is in AGEN, CRD, or LWB.
//
// msync (a.k.a. sync) and mbar will hold in LWB until all load/store
// resources are empty. AGEN and CRD are held empty until the msync/mbar
// commits.
//
// Most floating-point instructions, computational and move,
// have a 5-cycle latency. Divide takes longer (30 cycles). Instructions that
// update the CR take 2 cycles. Stores take 3 cycles and, as mentioned above,
// loads take 4 cycles (for L1 hit).
//
// This file defines the itinerary class data for the PPC 440 processor.
//
//===----------------------------------------------------------------------===//
def PPC440Itineraries : ProcessorItineraries<
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
[P440_DISS1, P440_DISS2, P440_FRACC, P440_IRACC, P440_IEXE1, P440_IEXE2,
P440_IWB, P440_LRACC, P440_JEXE1, P440_JEXE2, P440_JWB, P440_AGEN, P440_CRD,
P440_LWB, P440_FEXE1, P440_FEXE2, P440_FEXE3, P440_FEXE4, P440_FEXE5,
P440_FEXE6, P440_FWB, P440_LWARX_Hold],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[P440_GPR_Bypass, P440_FPR_Bypass], [
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_IntSimple, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_IRACC, P440_LRACC]>,
InstrStage<1, [P440_IEXE1, P440_JEXE1]>,
InstrStage<1, [P440_IEXE2, P440_JEXE2]>,
InstrStage<1, [P440_IWB, P440_JWB]>],
Adjust PPC440 operand latencies The operand latencies for the PPC440 should be specified relative to dispatch, not relative to the initial fetch-and-decode stages. Because most instructions (ignoring bypass) wait in dispatch until their operands are ready, this is modeled as reading input operands "at dispatch" (0 cycles after issue), and so every input and output operand has 4 cycles subtracted from it. This could alter scheduling slightly, but I don't expect a large effect. llvm-svn: 195947
2013-11-29 13:59:00 +08:00
[2, 0, 0],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[P440_GPR_Bypass,
P440_GPR_Bypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_IntGeneral, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_IRACC, P440_LRACC]>,
InstrStage<1, [P440_IEXE1, P440_JEXE1]>,
InstrStage<1, [P440_IEXE2, P440_JEXE2]>,
InstrStage<1, [P440_IWB, P440_JWB]>],
Adjust PPC440 operand latencies The operand latencies for the PPC440 should be specified relative to dispatch, not relative to the initial fetch-and-decode stages. Because most instructions (ignoring bypass) wait in dispatch until their operands are ready, this is modeled as reading input operands "at dispatch" (0 cycles after issue), and so every input and output operand has 4 cycles subtracted from it. This could alter scheduling slightly, but I don't expect a large effect. llvm-svn: 195947
2013-11-29 13:59:00 +08:00
[2, 0, 0],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[P440_GPR_Bypass,
P440_GPR_Bypass, P440_GPR_Bypass]>,
[PowerPC] Better scheduling for isel on P7/P8 isel is actually a cracked instruction on the P7/P8, and must start a dispatch group. The scheduling model should reflect this so that we don't bunch too many of them together when possible. Thanks to Bill Schmidt and Pat Haugen for helping to sort this out. llvm-svn: 227758
2015-02-02 01:52:16 +08:00
InstrItinData<IIC_IntISEL, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
InstrStage<1, [P440_IRACC, P440_LRACC]>,
InstrStage<1, [P440_IEXE1, P440_JEXE1]>,
InstrStage<1, [P440_IEXE2, P440_JEXE2]>,
InstrStage<1, [P440_IWB, P440_JWB]>],
[2, 0, 0, 0],
[P440_GPR_Bypass,
P440_GPR_Bypass, P440_GPR_Bypass, NoBypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_IntCompare, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_IRACC, P440_LRACC]>,
InstrStage<1, [P440_IEXE1, P440_JEXE1]>,
InstrStage<1, [P440_IEXE2, P440_JEXE2]>,
InstrStage<1, [P440_IWB, P440_JWB]>],
Adjust PPC440 operand latencies The operand latencies for the PPC440 should be specified relative to dispatch, not relative to the initial fetch-and-decode stages. Because most instructions (ignoring bypass) wait in dispatch until their operands are ready, this is modeled as reading input operands "at dispatch" (0 cycles after issue), and so every input and output operand has 4 cycles subtracted from it. This could alter scheduling slightly, but I don't expect a large effect. llvm-svn: 195947
2013-11-29 13:59:00 +08:00
[2, 0, 0],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_GPR_Bypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_IntDivW, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_IRACC]>,
InstrStage<1, [P440_IEXE1]>,
InstrStage<1, [P440_IEXE2]>,
InstrStage<33, [P440_IWB]>],
Adjust PPC440 operand latencies The operand latencies for the PPC440 should be specified relative to dispatch, not relative to the initial fetch-and-decode stages. Because most instructions (ignoring bypass) wait in dispatch until their operands are ready, this is modeled as reading input operands "at dispatch" (0 cycles after issue), and so every input and output operand has 4 cycles subtracted from it. This could alter scheduling slightly, but I don't expect a large effect. llvm-svn: 195947
2013-11-29 13:59:00 +08:00
[36, 0, 0],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_GPR_Bypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_IntMFFS, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_IRACC]>,
InstrStage<1, [P440_IEXE1]>,
InstrStage<1, [P440_IEXE2]>,
InstrStage<1, [P440_IWB]>],
Adjust PPC440 operand latencies The operand latencies for the PPC440 should be specified relative to dispatch, not relative to the initial fetch-and-decode stages. Because most instructions (ignoring bypass) wait in dispatch until their operands are ready, this is modeled as reading input operands "at dispatch" (0 cycles after issue), and so every input and output operand has 4 cycles subtracted from it. This could alter scheduling slightly, but I don't expect a large effect. llvm-svn: 195947
2013-11-29 13:59:00 +08:00
[3, 0, 0],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[P440_GPR_Bypass,
P440_GPR_Bypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_IntMTFSB0, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_IRACC]>,
InstrStage<1, [P440_IEXE1]>,
InstrStage<1, [P440_IEXE2]>,
InstrStage<1, [P440_IWB]>],
Adjust PPC440 operand latencies The operand latencies for the PPC440 should be specified relative to dispatch, not relative to the initial fetch-and-decode stages. Because most instructions (ignoring bypass) wait in dispatch until their operands are ready, this is modeled as reading input operands "at dispatch" (0 cycles after issue), and so every input and output operand has 4 cycles subtracted from it. This could alter scheduling slightly, but I don't expect a large effect. llvm-svn: 195947
2013-11-29 13:59:00 +08:00
[3, 0, 0],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[P440_GPR_Bypass,
P440_GPR_Bypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_IntMulHW, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_IRACC]>,
InstrStage<1, [P440_IEXE1]>,
InstrStage<1, [P440_IEXE2]>,
InstrStage<1, [P440_IWB]>],
Adjust PPC440 operand latencies The operand latencies for the PPC440 should be specified relative to dispatch, not relative to the initial fetch-and-decode stages. Because most instructions (ignoring bypass) wait in dispatch until their operands are ready, this is modeled as reading input operands "at dispatch" (0 cycles after issue), and so every input and output operand has 4 cycles subtracted from it. This could alter scheduling slightly, but I don't expect a large effect. llvm-svn: 195947
2013-11-29 13:59:00 +08:00
[4, 0, 0],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_GPR_Bypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_IntMulHWU, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_IRACC]>,
InstrStage<1, [P440_IEXE1]>,
InstrStage<1, [P440_IEXE2]>,
InstrStage<1, [P440_IWB]>],
Adjust PPC440 operand latencies The operand latencies for the PPC440 should be specified relative to dispatch, not relative to the initial fetch-and-decode stages. Because most instructions (ignoring bypass) wait in dispatch until their operands are ready, this is modeled as reading input operands "at dispatch" (0 cycles after issue), and so every input and output operand has 4 cycles subtracted from it. This could alter scheduling slightly, but I don't expect a large effect. llvm-svn: 195947
2013-11-29 13:59:00 +08:00
[4, 0, 0],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_GPR_Bypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_IntMulLI, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_IRACC]>,
InstrStage<1, [P440_IEXE1]>,
InstrStage<1, [P440_IEXE2]>,
InstrStage<1, [P440_IWB]>],
Adjust PPC440 operand latencies The operand latencies for the PPC440 should be specified relative to dispatch, not relative to the initial fetch-and-decode stages. Because most instructions (ignoring bypass) wait in dispatch until their operands are ready, this is modeled as reading input operands "at dispatch" (0 cycles after issue), and so every input and output operand has 4 cycles subtracted from it. This could alter scheduling slightly, but I don't expect a large effect. llvm-svn: 195947
2013-11-29 13:59:00 +08:00
[4, 0, 0],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_GPR_Bypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_IntRotate, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_IRACC, P440_LRACC]>,
InstrStage<1, [P440_IEXE1, P440_JEXE1]>,
InstrStage<1, [P440_IEXE2, P440_JEXE2]>,
InstrStage<1, [P440_IWB, P440_JWB]>],
Adjust PPC440 operand latencies The operand latencies for the PPC440 should be specified relative to dispatch, not relative to the initial fetch-and-decode stages. Because most instructions (ignoring bypass) wait in dispatch until their operands are ready, this is modeled as reading input operands "at dispatch" (0 cycles after issue), and so every input and output operand has 4 cycles subtracted from it. This could alter scheduling slightly, but I don't expect a large effect. llvm-svn: 195947
2013-11-29 13:59:00 +08:00
[2, 0, 0],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[P440_GPR_Bypass,
P440_GPR_Bypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_IntShift, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_IRACC, P440_LRACC]>,
InstrStage<1, [P440_IEXE1, P440_JEXE1]>,
InstrStage<1, [P440_IEXE2, P440_JEXE2]>,
InstrStage<1, [P440_IWB, P440_JWB]>],
Adjust PPC440 operand latencies The operand latencies for the PPC440 should be specified relative to dispatch, not relative to the initial fetch-and-decode stages. Because most instructions (ignoring bypass) wait in dispatch until their operands are ready, this is modeled as reading input operands "at dispatch" (0 cycles after issue), and so every input and output operand has 4 cycles subtracted from it. This could alter scheduling slightly, but I don't expect a large effect. llvm-svn: 195947
2013-11-29 13:59:00 +08:00
[2, 0, 0],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[P440_GPR_Bypass,
P440_GPR_Bypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_IntTrapW, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_IRACC]>,
InstrStage<1, [P440_IEXE1]>,
InstrStage<1, [P440_IEXE2]>,
InstrStage<1, [P440_IWB]>],
Adjust PPC440 operand latencies The operand latencies for the PPC440 should be specified relative to dispatch, not relative to the initial fetch-and-decode stages. Because most instructions (ignoring bypass) wait in dispatch until their operands are ready, this is modeled as reading input operands "at dispatch" (0 cycles after issue), and so every input and output operand has 4 cycles subtracted from it. This could alter scheduling slightly, but I don't expect a large effect. llvm-svn: 195947
2013-11-29 13:59:00 +08:00
[2, 0],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[P440_GPR_Bypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_BrB, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_IRACC]>,
InstrStage<1, [P440_IEXE1]>,
InstrStage<1, [P440_IEXE2]>,
InstrStage<1, [P440_IWB]>],
Adjust PPC440 operand latencies The operand latencies for the PPC440 should be specified relative to dispatch, not relative to the initial fetch-and-decode stages. Because most instructions (ignoring bypass) wait in dispatch until their operands are ready, this is modeled as reading input operands "at dispatch" (0 cycles after issue), and so every input and output operand has 4 cycles subtracted from it. This could alter scheduling slightly, but I don't expect a large effect. llvm-svn: 195947
2013-11-29 13:59:00 +08:00
[4, 0],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_BrCR, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_IRACC]>,
InstrStage<1, [P440_IEXE1]>,
InstrStage<1, [P440_IEXE2]>,
InstrStage<1, [P440_IWB]>],
Adjust PPC440 operand latencies The operand latencies for the PPC440 should be specified relative to dispatch, not relative to the initial fetch-and-decode stages. Because most instructions (ignoring bypass) wait in dispatch until their operands are ready, this is modeled as reading input operands "at dispatch" (0 cycles after issue), and so every input and output operand has 4 cycles subtracted from it. This could alter scheduling slightly, but I don't expect a large effect. llvm-svn: 195947
2013-11-29 13:59:00 +08:00
[4, 0, 0],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_GPR_Bypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_BrMCR, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_IRACC]>,
InstrStage<1, [P440_IEXE1]>,
InstrStage<1, [P440_IEXE2]>,
InstrStage<1, [P440_IWB]>],
Adjust PPC440 operand latencies The operand latencies for the PPC440 should be specified relative to dispatch, not relative to the initial fetch-and-decode stages. Because most instructions (ignoring bypass) wait in dispatch until their operands are ready, this is modeled as reading input operands "at dispatch" (0 cycles after issue), and so every input and output operand has 4 cycles subtracted from it. This could alter scheduling slightly, but I don't expect a large effect. llvm-svn: 195947
2013-11-29 13:59:00 +08:00
[4, 0, 0],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_GPR_Bypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_BrMCRX, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_IRACC]>,
InstrStage<1, [P440_IEXE1]>,
InstrStage<1, [P440_IEXE2]>,
InstrStage<1, [P440_IWB]>],
Adjust PPC440 operand latencies The operand latencies for the PPC440 should be specified relative to dispatch, not relative to the initial fetch-and-decode stages. Because most instructions (ignoring bypass) wait in dispatch until their operands are ready, this is modeled as reading input operands "at dispatch" (0 cycles after issue), and so every input and output operand has 4 cycles subtracted from it. This could alter scheduling slightly, but I don't expect a large effect. llvm-svn: 195947
2013-11-29 13:59:00 +08:00
[4, 0, 0],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_GPR_Bypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_LdStDCBA, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_LRACC]>,
InstrStage<1, [P440_AGEN]>,
InstrStage<1, [P440_CRD]>,
InstrStage<1, [P440_LWB]>],
Fixup PPC440 load/store operand latencies The operand latencies for loads and stores in the PPC440 itinerary were wrong (the store operands are all inputs, and the "with update" (pre-increment) instructions need a latency for the additional output). llvm-svn: 195948
2013-11-29 14:19:43 +08:00
[1, 1],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_LdStDCBF, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_LRACC]>,
InstrStage<1, [P440_AGEN]>,
InstrStage<1, [P440_CRD]>,
InstrStage<1, [P440_LWB]>],
Fixup PPC440 load/store operand latencies The operand latencies for loads and stores in the PPC440 itinerary were wrong (the store operands are all inputs, and the "with update" (pre-increment) instructions need a latency for the additional output). llvm-svn: 195948
2013-11-29 14:19:43 +08:00
[1, 1],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_LdStDCBI, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_LRACC]>,
InstrStage<1, [P440_AGEN]>,
InstrStage<1, [P440_CRD]>,
InstrStage<1, [P440_LWB]>],
Fixup PPC440 load/store operand latencies The operand latencies for loads and stores in the PPC440 itinerary were wrong (the store operands are all inputs, and the "with update" (pre-increment) instructions need a latency for the additional output). llvm-svn: 195948
2013-11-29 14:19:43 +08:00
[1, 1],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_LdStLoad, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_LRACC]>,
InstrStage<1, [P440_AGEN]>,
InstrStage<1, [P440_CRD]>,
InstrStage<2, [P440_LWB]>],
Fixup PPC440 load/store operand latencies The operand latencies for loads and stores in the PPC440 itinerary were wrong (the store operands are all inputs, and the "with update" (pre-increment) instructions need a latency for the additional output). llvm-svn: 195948
2013-11-29 14:19:43 +08:00
[5, 1, 1],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[P440_GPR_Bypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_LdStLoadUpd,[InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_LRACC]>,
InstrStage<1, [P440_AGEN]>,
InstrStage<1, [P440_CRD]>,
InstrStage<2, [P440_LWB]>],
Fixup PPC440 load/store operand latencies The operand latencies for loads and stores in the PPC440 itinerary were wrong (the store operands are all inputs, and the "with update" (pre-increment) instructions need a latency for the additional output). llvm-svn: 195948
2013-11-29 14:19:43 +08:00
[5, 2, 1, 1],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[P440_GPR_Bypass, P440_GPR_Bypass]>,
Split some PPC itinerary classes In preparation for adding scheduling definitions for the POWER7, split some PPC itinerary classes so that the P7's latencies and hazards can be better described. For the most part, this means differentiating indexed from non-index pre-increment loads and stores. Also, differentiate single from double-precision sqrt. No functionality change intended (except for a more-specific latency for single-precision sqrt on the A2). llvm-svn: 195980
2013-12-01 04:41:13 +08:00
InstrItinData<IIC_LdStLoadUpdX,[InstrStage<1, [P440_DISS1, P440_DISS2]>,
InstrStage<1, [P440_LRACC]>,
InstrStage<1, [P440_AGEN]>,
InstrStage<1, [P440_CRD]>,
InstrStage<2, [P440_LWB]>],
[5, 2, 1, 1],
[P440_GPR_Bypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_LdStStore, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_LRACC]>,
InstrStage<1, [P440_AGEN]>,
InstrStage<1, [P440_CRD]>,
InstrStage<2, [P440_LWB]>],
Fixup PPC440 load/store operand latencies The operand latencies for loads and stores in the PPC440 itinerary were wrong (the store operands are all inputs, and the "with update" (pre-increment) instructions need a latency for the additional output). llvm-svn: 195948
2013-11-29 14:19:43 +08:00
[1, 1, 1],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_LdStStoreUpd,[InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_LRACC]>,
InstrStage<1, [P440_AGEN]>,
InstrStage<1, [P440_CRD]>,
InstrStage<2, [P440_LWB]>],
Fixup PPC440 load/store operand latencies The operand latencies for loads and stores in the PPC440 itinerary were wrong (the store operands are all inputs, and the "with update" (pre-increment) instructions need a latency for the additional output). llvm-svn: 195948
2013-11-29 14:19:43 +08:00
[2, 1, 1, 1],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_LdStICBI, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_LRACC]>,
InstrStage<1, [P440_AGEN]>,
InstrStage<1, [P440_CRD]>,
InstrStage<1, [P440_LWB]>],
Fixup PPC440 load/store operand latencies The operand latencies for loads and stores in the PPC440 itinerary were wrong (the store operands are all inputs, and the "with update" (pre-increment) instructions need a latency for the additional output). llvm-svn: 195948
2013-11-29 14:19:43 +08:00
[4, 1, 1],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_LdStSTFD, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_LRACC]>,
InstrStage<1, [P440_AGEN]>,
InstrStage<1, [P440_CRD]>,
InstrStage<1, [P440_LWB]>],
Fixup PPC440 load/store operand latencies The operand latencies for loads and stores in the PPC440 itinerary were wrong (the store operands are all inputs, and the "with update" (pre-increment) instructions need a latency for the additional output). llvm-svn: 195948
2013-11-29 14:19:43 +08:00
[1, 1, 1],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_GPR_Bypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_LdStSTFDU, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_LRACC]>,
InstrStage<1, [P440_AGEN]>,
InstrStage<1, [P440_CRD]>,
InstrStage<1, [P440_LWB]>],
Fixup PPC440 load/store operand latencies The operand latencies for loads and stores in the PPC440 itinerary were wrong (the store operands are all inputs, and the "with update" (pre-increment) instructions need a latency for the additional output). llvm-svn: 195948
2013-11-29 14:19:43 +08:00
[2, 1, 1, 1],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_GPR_Bypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_LdStLFD, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_LRACC]>,
InstrStage<1, [P440_AGEN]>,
InstrStage<1, [P440_CRD]>,
InstrStage<2, [P440_LWB]>],
Adjust PPC440 operand latencies The operand latencies for the PPC440 should be specified relative to dispatch, not relative to the initial fetch-and-decode stages. Because most instructions (ignoring bypass) wait in dispatch until their operands are ready, this is modeled as reading input operands "at dispatch" (0 cycles after issue), and so every input and output operand has 4 cycles subtracted from it. This could alter scheduling slightly, but I don't expect a large effect. llvm-svn: 195947
2013-11-29 13:59:00 +08:00
[5, 1, 1],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_GPR_Bypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_LdStLFDU, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_LRACC]>,
InstrStage<1, [P440_AGEN]>,
InstrStage<1, [P440_CRD]>,
InstrStage<1, [P440_LWB]>],
Fixup PPC440 load/store operand latencies The operand latencies for loads and stores in the PPC440 itinerary were wrong (the store operands are all inputs, and the "with update" (pre-increment) instructions need a latency for the additional output). llvm-svn: 195948
2013-11-29 14:19:43 +08:00
[5, 2, 1, 1],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_GPR_Bypass, P440_GPR_Bypass]>,
Split some PPC itinerary classes In preparation for adding scheduling definitions for the POWER7, split some PPC itinerary classes so that the P7's latencies and hazards can be better described. For the most part, this means differentiating indexed from non-index pre-increment loads and stores. Also, differentiate single from double-precision sqrt. No functionality change intended (except for a more-specific latency for single-precision sqrt on the A2). llvm-svn: 195980
2013-12-01 04:41:13 +08:00
InstrItinData<IIC_LdStLFDUX, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
InstrStage<1, [P440_LRACC]>,
InstrStage<1, [P440_AGEN]>,
InstrStage<1, [P440_CRD]>,
InstrStage<1, [P440_LWB]>],
[5, 2, 1, 1],
[NoBypass, P440_GPR_Bypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_LdStLHA, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_LRACC]>,
InstrStage<1, [P440_AGEN]>,
InstrStage<1, [P440_CRD]>,
InstrStage<1, [P440_LWB]>],
Fixup PPC440 load/store operand latencies The operand latencies for loads and stores in the PPC440 itinerary were wrong (the store operands are all inputs, and the "with update" (pre-increment) instructions need a latency for the additional output). llvm-svn: 195948
2013-11-29 14:19:43 +08:00
[4, 1, 1],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_LdStLHAU, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_LRACC]>,
InstrStage<1, [P440_AGEN]>,
InstrStage<1, [P440_CRD]>,
InstrStage<1, [P440_LWB]>],
Fixup PPC440 load/store operand latencies The operand latencies for loads and stores in the PPC440 itinerary were wrong (the store operands are all inputs, and the "with update" (pre-increment) instructions need a latency for the additional output). llvm-svn: 195948
2013-11-29 14:19:43 +08:00
[4, 1, 1],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_GPR_Bypass]>,
Split some PPC itinerary classes In preparation for adding scheduling definitions for the POWER7, split some PPC itinerary classes so that the P7's latencies and hazards can be better described. For the most part, this means differentiating indexed from non-index pre-increment loads and stores. Also, differentiate single from double-precision sqrt. No functionality change intended (except for a more-specific latency for single-precision sqrt on the A2). llvm-svn: 195980
2013-12-01 04:41:13 +08:00
InstrItinData<IIC_LdStLHAUX, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
InstrStage<1, [P440_LRACC]>,
InstrStage<1, [P440_AGEN]>,
InstrStage<1, [P440_CRD]>,
InstrStage<1, [P440_LWB]>],
[4, 1, 1],
[NoBypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_LdStLMW, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_LRACC]>,
InstrStage<1, [P440_AGEN]>,
InstrStage<1, [P440_CRD]>,
InstrStage<1, [P440_LWB]>],
Fixup PPC440 load/store operand latencies The operand latencies for loads and stores in the PPC440 itinerary were wrong (the store operands are all inputs, and the "with update" (pre-increment) instructions need a latency for the additional output). llvm-svn: 195948
2013-11-29 14:19:43 +08:00
[4, 1, 1],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_LdStLWARX, [InstrStage<1, [P440_DISS1]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_IRACC], 0>,
InstrStage<4, [P440_LWARX_Hold], 0>,
InstrStage<1, [P440_LRACC]>,
InstrStage<1, [P440_AGEN]>,
InstrStage<1, [P440_CRD]>,
InstrStage<1, [P440_LWB]>],
Fixup PPC440 load/store operand latencies The operand latencies for loads and stores in the PPC440 itinerary were wrong (the store operands are all inputs, and the "with update" (pre-increment) instructions need a latency for the additional output). llvm-svn: 195948
2013-11-29 14:19:43 +08:00
[4, 1, 1],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_LdStSTD, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_LRACC]>,
InstrStage<1, [P440_AGEN]>,
InstrStage<1, [P440_CRD]>,
InstrStage<2, [P440_LWB]>],
Fixup PPC440 load/store operand latencies The operand latencies for loads and stores in the PPC440 itinerary were wrong (the store operands are all inputs, and the "with update" (pre-increment) instructions need a latency for the additional output). llvm-svn: 195948
2013-11-29 14:19:43 +08:00
[4, 1, 1],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_LdStSTDU, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_LRACC]>,
InstrStage<1, [P440_AGEN]>,
Split some PPC itinerary classes In preparation for adding scheduling definitions for the POWER7, split some PPC itinerary classes so that the P7's latencies and hazards can be better described. For the most part, this means differentiating indexed from non-index pre-increment loads and stores. Also, differentiate single from double-precision sqrt. No functionality change intended (except for a more-specific latency for single-precision sqrt on the A2). llvm-svn: 195980
2013-12-01 04:41:13 +08:00
InstrStage<1, [P440_CRD]>,
InstrStage<2, [P440_LWB]>],
[2, 1, 1, 1],
[NoBypass, P440_GPR_Bypass]>,
InstrItinData<IIC_LdStSTDUX, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
InstrStage<1, [P440_LRACC]>,
InstrStage<1, [P440_AGEN]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_CRD]>,
InstrStage<2, [P440_LWB]>],
Fixup PPC440 load/store operand latencies The operand latencies for loads and stores in the PPC440 itinerary were wrong (the store operands are all inputs, and the "with update" (pre-increment) instructions need a latency for the additional output). llvm-svn: 195948
2013-11-29 14:19:43 +08:00
[2, 1, 1, 1],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_LdStSTDCX, [InstrStage<1, [P440_DISS1]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_IRACC], 0>,
InstrStage<4, [P440_LWARX_Hold], 0>,
InstrStage<1, [P440_LRACC]>,
InstrStage<1, [P440_AGEN]>,
InstrStage<1, [P440_CRD]>,
InstrStage<1, [P440_LWB]>],
Fixup PPC440 load/store operand latencies The operand latencies for loads and stores in the PPC440 itinerary were wrong (the store operands are all inputs, and the "with update" (pre-increment) instructions need a latency for the additional output). llvm-svn: 195948
2013-11-29 14:19:43 +08:00
[4, 1, 1],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_LdStSTWCX, [InstrStage<1, [P440_DISS1]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_IRACC], 0>,
InstrStage<4, [P440_LWARX_Hold], 0>,
InstrStage<1, [P440_LRACC]>,
InstrStage<1, [P440_AGEN]>,
InstrStage<1, [P440_CRD]>,
InstrStage<1, [P440_LWB]>],
Fixup PPC440 load/store operand latencies The operand latencies for loads and stores in the PPC440 itinerary were wrong (the store operands are all inputs, and the "with update" (pre-increment) instructions need a latency for the additional output). llvm-svn: 195948
2013-11-29 14:19:43 +08:00
[4, 1, 1],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_LdStSync, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_LRACC]>,
InstrStage<3, [P440_AGEN], 1>,
InstrStage<2, [P440_CRD], 1>,
InstrStage<1, [P440_LWB]>]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_SprISYNC, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_FRACC], 0>,
InstrStage<1, [P440_LRACC], 0>,
InstrStage<1, [P440_IRACC]>,
InstrStage<1, [P440_FEXE1], 0>,
InstrStage<1, [P440_AGEN], 0>,
InstrStage<1, [P440_JEXE1], 0>,
InstrStage<1, [P440_IEXE1]>,
InstrStage<1, [P440_FEXE2], 0>,
InstrStage<1, [P440_CRD], 0>,
InstrStage<1, [P440_JEXE2], 0>,
InstrStage<1, [P440_IEXE2]>,
InstrStage<6, [P440_FEXE3], 0>,
InstrStage<6, [P440_LWB], 0>,
InstrStage<6, [P440_JWB], 0>,
InstrStage<6, [P440_IWB]>]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_SprMFSR, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_IRACC]>,
InstrStage<1, [P440_IEXE1]>,
InstrStage<1, [P440_IEXE2]>,
InstrStage<1, [P440_IWB]>],
Adjust PPC440 operand latencies The operand latencies for the PPC440 should be specified relative to dispatch, not relative to the initial fetch-and-decode stages. Because most instructions (ignoring bypass) wait in dispatch until their operands are ready, this is modeled as reading input operands "at dispatch" (0 cycles after issue), and so every input and output operand has 4 cycles subtracted from it. This could alter scheduling slightly, but I don't expect a large effect. llvm-svn: 195947
2013-11-29 13:59:00 +08:00
[2, 0],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[P440_GPR_Bypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_SprMTMSR, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_IRACC]>,
InstrStage<1, [P440_IEXE1]>,
InstrStage<1, [P440_IEXE2]>,
InstrStage<1, [P440_IWB]>],
Adjust PPC440 operand latencies The operand latencies for the PPC440 should be specified relative to dispatch, not relative to the initial fetch-and-decode stages. Because most instructions (ignoring bypass) wait in dispatch until their operands are ready, this is modeled as reading input operands "at dispatch" (0 cycles after issue), and so every input and output operand has 4 cycles subtracted from it. This could alter scheduling slightly, but I don't expect a large effect. llvm-svn: 195947
2013-11-29 13:59:00 +08:00
[2, 0],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[P440_GPR_Bypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_SprMTSR, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_IRACC]>,
InstrStage<1, [P440_IEXE1]>,
InstrStage<1, [P440_IEXE2]>,
InstrStage<3, [P440_IWB]>],
Adjust PPC440 operand latencies The operand latencies for the PPC440 should be specified relative to dispatch, not relative to the initial fetch-and-decode stages. Because most instructions (ignoring bypass) wait in dispatch until their operands are ready, this is modeled as reading input operands "at dispatch" (0 cycles after issue), and so every input and output operand has 4 cycles subtracted from it. This could alter scheduling slightly, but I don't expect a large effect. llvm-svn: 195947
2013-11-29 13:59:00 +08:00
[5, 0],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_SprTLBSYNC, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_IRACC]>,
InstrStage<1, [P440_IEXE1]>,
InstrStage<1, [P440_IEXE2]>,
InstrStage<1, [P440_IWB]>]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_SprMFCR, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_IRACC]>,
InstrStage<1, [P440_IEXE1]>,
InstrStage<1, [P440_IEXE2]>,
InstrStage<1, [P440_IWB]>],
Adjust PPC440 operand latencies The operand latencies for the PPC440 should be specified relative to dispatch, not relative to the initial fetch-and-decode stages. Because most instructions (ignoring bypass) wait in dispatch until their operands are ready, this is modeled as reading input operands "at dispatch" (0 cycles after issue), and so every input and output operand has 4 cycles subtracted from it. This could alter scheduling slightly, but I don't expect a large effect. llvm-svn: 195947
2013-11-29 13:59:00 +08:00
[4, 0],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_SprMFMSR, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_IRACC]>,
InstrStage<1, [P440_IEXE1]>,
InstrStage<1, [P440_IEXE2]>,
InstrStage<1, [P440_IWB]>],
Adjust PPC440 operand latencies The operand latencies for the PPC440 should be specified relative to dispatch, not relative to the initial fetch-and-decode stages. Because most instructions (ignoring bypass) wait in dispatch until their operands are ready, this is modeled as reading input operands "at dispatch" (0 cycles after issue), and so every input and output operand has 4 cycles subtracted from it. This could alter scheduling slightly, but I don't expect a large effect. llvm-svn: 195947
2013-11-29 13:59:00 +08:00
[3, 0],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[P440_GPR_Bypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_SprMFSPR, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_IRACC]>,
InstrStage<1, [P440_IEXE1]>,
InstrStage<1, [P440_IEXE2]>,
InstrStage<3, [P440_IWB]>],
Adjust PPC440 operand latencies The operand latencies for the PPC440 should be specified relative to dispatch, not relative to the initial fetch-and-decode stages. Because most instructions (ignoring bypass) wait in dispatch until their operands are ready, this is modeled as reading input operands "at dispatch" (0 cycles after issue), and so every input and output operand has 4 cycles subtracted from it. This could alter scheduling slightly, but I don't expect a large effect. llvm-svn: 195947
2013-11-29 13:59:00 +08:00
[6, 0],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_SprMFTB, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_IRACC]>,
InstrStage<1, [P440_IEXE1]>,
InstrStage<1, [P440_IEXE2]>,
InstrStage<3, [P440_IWB]>],
Adjust PPC440 operand latencies The operand latencies for the PPC440 should be specified relative to dispatch, not relative to the initial fetch-and-decode stages. Because most instructions (ignoring bypass) wait in dispatch until their operands are ready, this is modeled as reading input operands "at dispatch" (0 cycles after issue), and so every input and output operand has 4 cycles subtracted from it. This could alter scheduling slightly, but I don't expect a large effect. llvm-svn: 195947
2013-11-29 13:59:00 +08:00
[6, 0],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_SprMTSPR, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_IRACC]>,
InstrStage<1, [P440_IEXE1]>,
InstrStage<1, [P440_IEXE2]>,
InstrStage<3, [P440_IWB]>],
Adjust PPC440 operand latencies The operand latencies for the PPC440 should be specified relative to dispatch, not relative to the initial fetch-and-decode stages. Because most instructions (ignoring bypass) wait in dispatch until their operands are ready, this is modeled as reading input operands "at dispatch" (0 cycles after issue), and so every input and output operand has 4 cycles subtracted from it. This could alter scheduling slightly, but I don't expect a large effect. llvm-svn: 195947
2013-11-29 13:59:00 +08:00
[6, 0],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_SprMTSRIN, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_IRACC]>,
InstrStage<1, [P440_IEXE1]>,
InstrStage<1, [P440_IEXE2]>,
InstrStage<3, [P440_IWB]>],
Adjust PPC440 operand latencies The operand latencies for the PPC440 should be specified relative to dispatch, not relative to the initial fetch-and-decode stages. Because most instructions (ignoring bypass) wait in dispatch until their operands are ready, this is modeled as reading input operands "at dispatch" (0 cycles after issue), and so every input and output operand has 4 cycles subtracted from it. This could alter scheduling slightly, but I don't expect a large effect. llvm-svn: 195947
2013-11-29 13:59:00 +08:00
[6, 0],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_SprRFI, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_IRACC]>,
InstrStage<1, [P440_IEXE1]>,
InstrStage<1, [P440_IEXE2]>,
InstrStage<1, [P440_IWB]>],
Adjust PPC440 operand latencies The operand latencies for the PPC440 should be specified relative to dispatch, not relative to the initial fetch-and-decode stages. Because most instructions (ignoring bypass) wait in dispatch until their operands are ready, this is modeled as reading input operands "at dispatch" (0 cycles after issue), and so every input and output operand has 4 cycles subtracted from it. This could alter scheduling slightly, but I don't expect a large effect. llvm-svn: 195947
2013-11-29 13:59:00 +08:00
[4, 0],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_SprSC, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_IRACC]>,
InstrStage<1, [P440_IEXE1]>,
InstrStage<1, [P440_IEXE2]>,
InstrStage<1, [P440_IWB]>],
Adjust PPC440 operand latencies The operand latencies for the PPC440 should be specified relative to dispatch, not relative to the initial fetch-and-decode stages. Because most instructions (ignoring bypass) wait in dispatch until their operands are ready, this is modeled as reading input operands "at dispatch" (0 cycles after issue), and so every input and output operand has 4 cycles subtracted from it. This could alter scheduling slightly, but I don't expect a large effect. llvm-svn: 195947
2013-11-29 13:59:00 +08:00
[4, 0],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_GPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_FPGeneral, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_FRACC]>,
InstrStage<1, [P440_FEXE1]>,
InstrStage<1, [P440_FEXE2]>,
InstrStage<1, [P440_FEXE3]>,
InstrStage<1, [P440_FEXE4]>,
InstrStage<1, [P440_FEXE5]>,
InstrStage<1, [P440_FEXE6]>,
InstrStage<1, [P440_FWB]>],
Adjust PPC440 operand latencies The operand latencies for the PPC440 should be specified relative to dispatch, not relative to the initial fetch-and-decode stages. Because most instructions (ignoring bypass) wait in dispatch until their operands are ready, this is modeled as reading input operands "at dispatch" (0 cycles after issue), and so every input and output operand has 4 cycles subtracted from it. This could alter scheduling slightly, but I don't expect a large effect. llvm-svn: 195947
2013-11-29 13:59:00 +08:00
[6, 0, 0],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[P440_FPR_Bypass,
P440_FPR_Bypass, P440_FPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_FPAddSub, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_FRACC]>,
InstrStage<1, [P440_FEXE1]>,
InstrStage<1, [P440_FEXE2]>,
InstrStage<1, [P440_FEXE3]>,
InstrStage<1, [P440_FEXE4]>,
InstrStage<1, [P440_FEXE5]>,
InstrStage<1, [P440_FEXE6]>,
InstrStage<1, [P440_FWB]>],
Adjust PPC440 operand latencies The operand latencies for the PPC440 should be specified relative to dispatch, not relative to the initial fetch-and-decode stages. Because most instructions (ignoring bypass) wait in dispatch until their operands are ready, this is modeled as reading input operands "at dispatch" (0 cycles after issue), and so every input and output operand has 4 cycles subtracted from it. This could alter scheduling slightly, but I don't expect a large effect. llvm-svn: 195947
2013-11-29 13:59:00 +08:00
[6, 0, 0],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[P440_FPR_Bypass,
P440_FPR_Bypass, P440_FPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_FPCompare, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_FRACC]>,
InstrStage<1, [P440_FEXE1]>,
InstrStage<1, [P440_FEXE2]>,
InstrStage<1, [P440_FEXE3]>,
InstrStage<1, [P440_FEXE4]>,
InstrStage<1, [P440_FEXE5]>,
InstrStage<1, [P440_FEXE6]>,
InstrStage<1, [P440_FWB]>],
Adjust PPC440 operand latencies The operand latencies for the PPC440 should be specified relative to dispatch, not relative to the initial fetch-and-decode stages. Because most instructions (ignoring bypass) wait in dispatch until their operands are ready, this is modeled as reading input operands "at dispatch" (0 cycles after issue), and so every input and output operand has 4 cycles subtracted from it. This could alter scheduling slightly, but I don't expect a large effect. llvm-svn: 195947
2013-11-29 13:59:00 +08:00
[6, 0, 0],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[P440_FPR_Bypass, P440_FPR_Bypass,
P440_FPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_FPDivD, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_FRACC]>,
InstrStage<1, [P440_FEXE1]>,
InstrStage<1, [P440_FEXE2]>,
InstrStage<1, [P440_FEXE3]>,
InstrStage<1, [P440_FEXE4]>,
InstrStage<1, [P440_FEXE5]>,
InstrStage<1, [P440_FEXE6]>,
InstrStage<25, [P440_FWB]>],
Adjust PPC440 operand latencies The operand latencies for the PPC440 should be specified relative to dispatch, not relative to the initial fetch-and-decode stages. Because most instructions (ignoring bypass) wait in dispatch until their operands are ready, this is modeled as reading input operands "at dispatch" (0 cycles after issue), and so every input and output operand has 4 cycles subtracted from it. This could alter scheduling slightly, but I don't expect a large effect. llvm-svn: 195947
2013-11-29 13:59:00 +08:00
[31, 0, 0],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_FPR_Bypass, P440_FPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_FPDivS, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_FRACC]>,
InstrStage<1, [P440_FEXE1]>,
InstrStage<1, [P440_FEXE2]>,
InstrStage<1, [P440_FEXE3]>,
InstrStage<1, [P440_FEXE4]>,
InstrStage<1, [P440_FEXE5]>,
InstrStage<1, [P440_FEXE6]>,
InstrStage<13, [P440_FWB]>],
Adjust PPC440 operand latencies The operand latencies for the PPC440 should be specified relative to dispatch, not relative to the initial fetch-and-decode stages. Because most instructions (ignoring bypass) wait in dispatch until their operands are ready, this is modeled as reading input operands "at dispatch" (0 cycles after issue), and so every input and output operand has 4 cycles subtracted from it. This could alter scheduling slightly, but I don't expect a large effect. llvm-svn: 195947
2013-11-29 13:59:00 +08:00
[19, 0, 0],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[NoBypass, P440_FPR_Bypass, P440_FPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_FPFused, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_FRACC]>,
InstrStage<1, [P440_FEXE1]>,
InstrStage<1, [P440_FEXE2]>,
InstrStage<1, [P440_FEXE3]>,
InstrStage<1, [P440_FEXE4]>,
InstrStage<1, [P440_FEXE5]>,
InstrStage<1, [P440_FEXE6]>,
InstrStage<1, [P440_FWB]>],
Adjust PPC440 operand latencies The operand latencies for the PPC440 should be specified relative to dispatch, not relative to the initial fetch-and-decode stages. Because most instructions (ignoring bypass) wait in dispatch until their operands are ready, this is modeled as reading input operands "at dispatch" (0 cycles after issue), and so every input and output operand has 4 cycles subtracted from it. This could alter scheduling slightly, but I don't expect a large effect. llvm-svn: 195947
2013-11-29 13:59:00 +08:00
[6, 0, 0, 0],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[P440_FPR_Bypass,
P440_FPR_Bypass, P440_FPR_Bypass,
P440_FPR_Bypass]>,
Don't model the fetch and decode units for the PPC440 Modeling the fetch and decode units in the PPC440 itinerary does not add anything to the hazard detection capability (and so modeling them just wastes compile time). No functionality change intended. llvm-svn: 195946
2013-11-29 13:58:38 +08:00
InstrItinData<IIC_FPRes, [InstrStage<1, [P440_DISS1, P440_DISS2]>,
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
InstrStage<1, [P440_FRACC]>,
InstrStage<1, [P440_FEXE1]>,
InstrStage<1, [P440_FEXE2]>,
InstrStage<1, [P440_FEXE3]>,
InstrStage<1, [P440_FEXE4]>,
InstrStage<1, [P440_FEXE5]>,
InstrStage<1, [P440_FEXE6]>,
InstrStage<1, [P440_FWB]>],
Adjust PPC440 operand latencies The operand latencies for the PPC440 should be specified relative to dispatch, not relative to the initial fetch-and-decode stages. Because most instructions (ignoring bypass) wait in dispatch until their operands are ready, this is modeled as reading input operands "at dispatch" (0 cycles after issue), and so every input and output operand has 4 cycles subtracted from it. This could alter scheduling slightly, but I don't expect a large effect. llvm-svn: 195947
2013-11-29 13:59:00 +08:00
[6, 0],
Don't share functional units among the PPC itineraries Instead of sharing functional unit names between the various PPC itineraries, give each core its own unit names prefixed with the core name. This follows the convention used by other backends (such as ARM), and removes a non-obvious ordering dependency between the various PPCSchedule*.td files. No functionality change intended. llvm-svn: 195908
2013-11-28 14:05:59 +08:00
[P440_FPR_Bypass, P440_FPR_Bypass]>
Add PPC 440 scheduler and some associated tests (new files) llvm-svn: 142171
2011-10-17 12:03:55 +08:00
]>;
Create a PPC440 SchedMachineModel Some of the older PPC processor definitions don't have associated SchedMachineModels; correct this for the PPC440. llvm-svn: 195949
2013-11-29 14:32:17 +08:00
// ===---------------------------------------------------------------------===//
// PPC440 machine model for scheduling and other instruction cost heuristics.
def PPC440Model : SchedMachineModel {
let IssueWidth = 2; // 2 instructions are dispatched per cycle.
let LoadLatency = 5; // Optimistic load latency assuming bypass.
// This is overriden by OperandCycles if the
// Itineraries are queried instead.
TableGen: Check scheduling models for completeness TableGen checks at compiletime that for scheduling models with "CompleteModel = 1" one of the following holds: - Is marked with the hasNoSchedulingInfo flag - The instruction is a subclass of Sched - There are InstRW definitions in the scheduling model Typical steps necessary to complete a model: - Ensure all pseudo instructions that are expanded before machine scheduling (usually everything handled with EmitYYY() functions in XXXTargetLowering). - If a CPU does not support some instructions mark the corresponding resource unsupported: "WriteRes<WriteXXX, []> { let Unsupported = 1; }". - Add missing scheduling information. Differential Revision: http://reviews.llvm.org/D17747 llvm-svn: 262384
2016-03-02 04:03:21 +08:00
let CompleteModel = 0;
Create a PPC440 SchedMachineModel Some of the older PPC processor definitions don't have associated SchedMachineModels; correct this for the PPC440. llvm-svn: 195949
2013-11-29 14:32:17 +08:00
let Itineraries = PPC440Itineraries;
}