GCC中流水线描述

lazy_linux

在gcc/config/i386/ppro.md文件中，描述了Intel P6处理器中流水线的使用规则。
其中部分代码如下：
;; The P6 pipeline has three major components:
;;   1) the FETCH/DECODE unit, an in-order issue front-end
;;   2) the DISPATCH/EXECUTE unit, which is the out-of-order core
;;   3) the RETIRE unit, an in-order retirement unit
;;
;; So, the P6 CPUs have out-of-order cores, but the instruction decoder and
;; retirement unit are naturally in-order.
;;
;;                       BUS INTERFACE UNIT
;;                     /                   \
;;                L1 ICACHE             L1 DCACHE
;;              /     |     \              |     \
;;       DECODER0  DECODER1  DECODER2  DISP/EXEC  RETIRE
;;              \     |     /              |        |
;;            INSTRUCTION POOL   __________|_______/
;;          (inc. reorder buffer)
;;
;; Since the P6 CPUs execute instructions out-of-order, the most important
;; consideration in performance tuning is making sure enough micro-ops are
;; ready for execution in the out-of-order core, while not stalling the
;; decoder.
;;
;; TODO:
;; - Find a less crude way to model complex instructions, in
;;   particular how many cycles they take to be decoded.
;; - Include decoder latencies in the total reservation latencies.
;;   This isn't necessary right now because we assume for every
;;   instruction that it never blocks a decoder.
;; - Figure out where the p0 and p1 reservations come from.  These
;;   appear not to be in the manual
;; - Lots more because I'm sure this is still far from optimal

;; The ppro_idiv and ppro_fdiv automata are used to model issue
;; latencies of idiv and fdiv type insns.
(define_automaton "ppro_decoder,ppro_core,ppro_idiv,ppro_fdiv,ppro_load,ppro_store"

;; Simple instructions of the register-register form have only one uop.
;; Load instructions are also only one uop.  Store instructions decode to
;; two uops, and simple read-modify instructions also take two uops.
;; Simple instructions of the register-memory form have two to three uops.
;; Simple read-modify-write instructions have four uops.  The rules for
;; the decoder are simple:
;;  - an instruction with 1 uop can be decoded by any of the three
;;    decoders in one cycle.
;;  - an instruction with 1 to 4 uops can be decoded only by decoder 0
;;    but still in only one cycle.
;;  - a complex (microcode) instruction can also only be decoded by
;;    decoder 0, and this takes an unspecified number of cycles.
;;
;; The goal is to schedule such that we have a few-one-one uops sequence
;; in each cycle, to decode as many instructions per cycle as possible.
(define_cpu_unit "decoder0" "ppro_decoder"
(define_cpu_unit "decoder1" "ppro_decoder"
(define_cpu_unit "decoder2" "ppro_decoder"

;; We first wish to find an instruction for decoder0, so exclude
;; decoder1 and decoder2 from being reserved until decoder 0 is
;; reserved.
(presence_set "decoder1" "decoder0"
(presence_set "decoder2" "decoder0"

;; Most instructions can be decoded on any of the three decoders.
(define_reservation "decodern" "(decoder0|decoder1|decoder2)"

;; The out-of-order core has five pipelines.  During each cycle, the core
;; may dispatch zero or one uop on the port of any of the five pipelines
;; so the maximum number of dispatched uops per cycle is 5.  In practicer,
;; 3 uops per cycle is more realistic.
;;
;; Two of the five pipelines contain several execution units:
;;
;; Port 0        Port 1                Port 2                Port 3                Port 4
;; ALU                ALU                LOAD                SAC                SDA
;; FPU                JUE
;; AGU                MMX
;; MMX                P3FPU
;; P3FPU
;;
;; (SAC=Store Address Calculation, SDA=Store Data Unit, P3FPU = SSE unit,
;;  JUE = Jump Execution Unit, AGU = Address Generation Unit)
;;
(define_cpu_unit "p0,p1" "ppro_core"
(define_cpu_unit "p2" "ppro_load"
(define_cpu_unit "p3,p4" "ppro_store"
(define_cpu_unit "idiv" "ppro_idiv")
(define_cpu_unit "fdiv" "ppro_fdiv")

;; Only the irregular instructions have to be modeled here.  A load
;; increases the latency by 2 or 3, or by nothing if the manual gives
;; a latency already.  Store latencies are not accounted for.
;;
;; The simple instructions follow a very regular pattern of 1 uop per
;; reg-reg operation, 1 uop per load on port 2. and 2 uops per store
;; on port 4 and port 3.  These instructions are modelled at the bottom
;; of this file.
;;
;; For microcoded instructions we don't know how many uops are produced.
;; These instructions are the "complex" ones in the Intel manuals.  All
;; we _do_ know is that they typically produce four or more uops, so
;; they can only be decoded on decoder0.  Modelling their latencies
;; doesn't make sense because we don't know how these instructions are
;; executed in the core.  So we just model that they can only be decoded
;; on decoder 0, and say that it takes a little while before the result
;; is available.
(define_insn_reservation "ppro_complex_insn" 6
                         (and (eq_attr "cpu" "pentiumpro")
                              (eq_attr "type" "other,multi,call,callv,str"))
                         "decoder0")

;; imov with memory operands does not use the integer units.
(define_insn_reservation "ppro_imov" 1
                         (and (eq_attr "cpu" "pentiumpro")
                              (and (eq_attr "memory" "none")
                                   (eq_attr "type" "imov")))
                         "decodern,(p0|p1)")

比如最后一个define_insn_reservation “ppro_imov”
其中1指的延迟
”decodern,(p0|p1)"表示该指令使用decodern（即三个译码器中的任何一个），还使用p0或者p1流水线
请问延迟1和“decodern,(p0|p1)"是什么关系？怎么理解呢？
有什么详细的资料介绍吗？
不胜感谢！