1238423Sjhb;; DFA scheduling description for SH4. 2238423Sjhb;; Copyright (C) 2004-2020 Free Software Foundation, Inc. 3238423Sjhb 4238423Sjhb;; This file is part of GCC. 5238423Sjhb 6238423Sjhb;; GCC is free software; you can redistribute it and/or modify 7238423Sjhb;; it under the terms of the GNU General Public License as published by 8238423Sjhb;; the Free Software Foundation; either version 3, or (at your option) 9238423Sjhb;; any later version. 10238423Sjhb 11238423Sjhb;; GCC is distributed in the hope that it will be useful, 12238423Sjhb;; but WITHOUT ANY WARRANTY; without even the implied warranty of 13238423Sjhb;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 14238423Sjhb;; GNU General Public License for more details. 15238423Sjhb 16238423Sjhb;; You should have received a copy of the GNU General Public License 17238423Sjhb;; along with GCC; see the file COPYING3. If not see 18238423Sjhb;; <http://www.gnu.org/licenses/>. 19238423Sjhb 20238423Sjhb;; Load and store instructions save a cycle if they are aligned on a 21238423Sjhb;; four byte boundary. Using a function unit for stores encourages 22238423Sjhb;; gcc to separate load and store instructions by one instruction, 23238423Sjhb;; which makes it more likely that the linker will be able to word 24238423Sjhb;; align them when relaxing. 25238423Sjhb 26238423Sjhb;; The following description models the SH4 pipeline using the DFA based 27238423Sjhb;; scheduler. The DFA based description is better way to model a 28238423Sjhb;; superscalar pipeline as compared to function unit reservation model. 29238423Sjhb;; 1. The function unit based model is oriented to describe at most one 30238423Sjhb;; unit reservation by each insn. It is difficult to model unit reservations 31238423Sjhb;; in multiple pipeline units by same insn. This can be done using DFA 32238423Sjhb;; based description. 33238423Sjhb;; 2. The execution performance of DFA based scheduler does not depend on 34238423Sjhb;; processor complexity. 35238423Sjhb;; 3. Writing all unit reservations for an instruction class is a more natural 36238423Sjhb;; description of the pipeline and makes the interface to the hazard 37238423Sjhb;; recognizer simpler than the old function unit based model. 38238423Sjhb;; 4. The DFA model is richer and is a part of greater overall framework 39238423Sjhb;; of RCSP. 40238423Sjhb 41238423Sjhb 42238423Sjhb;; Two automata are defined to reduce number of states 43238423Sjhb;; which a single large automaton will have. (Factoring) 44238423Sjhb(define_automaton "inst_pipeline,fpu_pipe") 45238423Sjhb 46238423Sjhb;; This unit is basically the decode unit of the processor. 47238423Sjhb;; Since SH4 is a dual issue machine,it is as if there are two 48238423Sjhb;; units so that any insn can be processed by either one 49238423Sjhb;; of the decoding unit. 50238423Sjhb(define_cpu_unit "pipe_01,pipe_02" "inst_pipeline") 51238423Sjhb 52238423Sjhb 53238423Sjhb;; The fixed point arithmetic calculator(?? EX Unit). 54238423Sjhb(define_cpu_unit "int" "inst_pipeline") 55238423Sjhb 56238423Sjhb;; f1_1 and f1_2 are floating point units.Actually there is 57238423Sjhb;; a f1 unit which can overlap with other f1 unit but 58238423Sjhb;; not another F1 unit.It is as though there were two 59238423Sjhb;; f1 units. 60238423Sjhb(define_cpu_unit "f1_1,f1_2" "fpu_pipe") 61238423Sjhb 62238423Sjhb;; The floating point units (except FS - F2 always precedes it.) 63238423Sjhb(define_cpu_unit "F0,F1,F2,F3" "fpu_pipe") 64238423Sjhb 65238423Sjhb;; This is basically the MA unit of SH4 66238423Sjhb;; used in LOAD/STORE pipeline. 67238423Sjhb(define_cpu_unit "memory" "inst_pipeline") 68238423Sjhb 69238423Sjhb;; However, there are LS group insns that don't use it, even ones that 70238423Sjhb;; complete in 0 cycles. So we use an extra unit for the issue of LS insns. 71238423Sjhb(define_cpu_unit "load_store" "inst_pipeline") 72238423Sjhb 73238423Sjhb;; The address calculator used for branch instructions. 74238423Sjhb;; This will be reserved after "issue" of branch instructions 75238423Sjhb;; and this is to make sure that no two branch instructions 76238423Sjhb;; can be issued in parallel. 77238423Sjhb 78238423Sjhb(define_cpu_unit "pcr_addrcalc" "inst_pipeline") 79238423Sjhb 80238423Sjhb;; ---------------------------------------------------- 81238423Sjhb;; This reservation is to simplify the dual issue description. 82238423Sjhb(define_reservation "issue" "pipe_01|pipe_02") 83238423Sjhb 84238423Sjhb;; This is to express the locking of D stage. 85238423Sjhb;; Note that the issue of a CO group insn also effectively locks the D stage. 86238423Sjhb(define_reservation "d_lock" "pipe_01+pipe_02") 87238423Sjhb 88238423Sjhb;; Every FE instruction but fipr / ftrv starts with issue and this. 89238423Sjhb(define_reservation "F01" "F0+F1") 90238423Sjhb 91238423Sjhb;; This is to simplify description where F1,F2,FS 92238423Sjhb;; are used simultaneously. 93238423Sjhb(define_reservation "fpu" "F1+F2") 94238423Sjhb 95238423Sjhb;; This is to highlight the fact that f1 96238423Sjhb;; cannot overlap with F1. 97238423Sjhb(exclusion_set "f1_1,f1_2" "F1") 98238423Sjhb 99238423Sjhb(define_insn_reservation "nil" 0 (eq_attr "type" "nil") "nothing") 100238423Sjhb 101238423Sjhb;; Although reg moves have a latency of zero 102238423Sjhb;; we need to highlight that they use D stage 103238423Sjhb;; for one cycle. 104238423Sjhb 105238423Sjhb;; Group: MT 106238423Sjhb(define_insn_reservation "reg_mov" 0 107238423Sjhb (and (eq_attr "pipe_model" "sh4") 108238423Sjhb (eq_attr "type" "move")) 109238423Sjhb "issue") 110238423Sjhb 111238423Sjhb;; Group: LS 112238423Sjhb(define_insn_reservation "freg_mov" 0 113238423Sjhb (and (eq_attr "pipe_model" "sh4") 114238423Sjhb (eq_attr "type" "fmove")) 115238423Sjhb "issue+load_store") 116238423Sjhb 117238423Sjhb;; We don't model all pipeline stages; we model the issue ('D') stage 118238423Sjhb;; inasmuch as we allow only two instructions to issue simultaneously, 119238423Sjhb;; and CO instructions prevent any simultaneous issue of another instruction. 120238423Sjhb;; (This uses pipe_01 and pipe_02). 121238423Sjhb;; Double issue of EX insns is prevented by using the int unit in the EX stage. 122238423Sjhb;; Double issue of EX / BR insns is prevented by using the int unit / 123238423Sjhb;; pcr_addrcalc unit in the EX stage. 124238423Sjhb;; Double issue of BR / LS instructions is prevented by using the 125238423Sjhb;; pcr_addrcalc / load_store unit in the issue cycle. 126238423Sjhb;; Double issue of FE instructions is prevented by using F0 in the first 127238423Sjhb;; pipeline stage after the first D stage. 128238423Sjhb;; There is no need to describe the [ES]X / [MN]A / S stages after a D stage 129238423Sjhb;; (except in the cases outlined above), nor to describe the FS stage after 130238423Sjhb;; the F2 stage. 131238423Sjhb 132238423Sjhb;; Other MT group instructions(1 step operations) 133238423Sjhb;; Group: MT 134238423Sjhb;; Latency: 1 135238423Sjhb;; Issue Rate: 1 136238423Sjhb(define_insn_reservation "mt" 1 137238423Sjhb (and (eq_attr "pipe_model" "sh4") 138238423Sjhb (eq_attr "type" "mt_group")) 139238423Sjhb "issue") 140238423Sjhb 141238423Sjhb;; Fixed Point Arithmetic Instructions(1 step operations) 142238423Sjhb;; Group: EX 143238423Sjhb;; Latency: 1 144238423Sjhb;; Issue Rate: 1 145238423Sjhb(define_insn_reservation "sh4_simple_arith" 1 146238423Sjhb (and (eq_attr "pipe_model" "sh4") 147238423Sjhb (eq_attr "insn_class" "ex_group")) 148238423Sjhb "issue,int") 149238423Sjhb 150238423Sjhb;; Load and store instructions have no alignment peculiarities for the SH4, 151238423Sjhb;; but they use the load-store unit, which they share with the fmove type 152238423Sjhb;; insns (fldi[01]; fmov frn,frm; flds; fsts; fabs; fneg) . 153238423Sjhb;; Loads have a latency of two. 154238423Sjhb;; However, call insns can only paired with a preceding insn, and have 155238423Sjhb;; a delay slot, so that we want two more insns to be scheduled between the 156238423Sjhb;; load of the function address and the call. This is equivalent to a 157238423Sjhb;; latency of three. 158238423Sjhb;; ADJUST_COST can only properly handle reductions of the cost, so we 159238423Sjhb;; use a latency of three here, which gets multiplied by 10 to yield 30. 160238423Sjhb;; We only do this for SImode loads of general registers, to make the work 161238423Sjhb;; for ADJUST_COST easier. 162238423Sjhb 163238423Sjhb;; Load Store instructions. (MOV.[BWL]@(d,GBR) 164238423Sjhb;; Group: LS 165238423Sjhb;; Latency: 2 166238423Sjhb;; Issue Rate: 1 167238423Sjhb(define_insn_reservation "sh4_load" 2 168238423Sjhb (and (eq_attr "pipe_model" "sh4") 169238423Sjhb (eq_attr "type" "load,pcload")) 170238423Sjhb "issue+load_store,nothing,memory") 171238423Sjhb 172238423Sjhb;; calls / sfuncs need an extra instruction for their delay slot. 173238423Sjhb;; Moreover, estimating the latency for SImode loads as 3 will also allow 174238423Sjhb;; adjust_cost to meaningfully bump it back up to 3 if they load the shift 175238423Sjhb;; count of a dynamic shift. 176238423Sjhb(define_insn_reservation "sh4_load_si" 3 177238423Sjhb (and (eq_attr "pipe_model" "sh4") 178238423Sjhb (eq_attr "type" "load_si,pcload_si")) 179238423Sjhb "issue+load_store,nothing,memory") 180238423Sjhb 181238423Sjhb;; (define_bypass 2 "sh4_load_si" "!sh4_call") 182238423Sjhb 183238423Sjhb;; The load latency is upped to three higher if the dependent insn does 184238423Sjhb;; double precision computation. We want the 'default' latency to reflect 185238423Sjhb;; that increased latency because otherwise the insn priorities won't 186238423Sjhb;; allow proper scheduling. 187238423Sjhb(define_insn_reservation "sh4_fload" 3 188238423Sjhb (and (eq_attr "pipe_model" "sh4") 189238423Sjhb (eq_attr "type" "fload,pcfload")) 190238423Sjhb "issue+load_store,nothing,memory") 191238423Sjhb 192238423Sjhb;; (define_bypass 2 "sh4_fload" "!") 193238423Sjhb 194238423Sjhb(define_insn_reservation "sh4_store" 1 195238423Sjhb (and (eq_attr "pipe_model" "sh4") 196238423Sjhb (eq_attr "type" "store,fstore")) 197238423Sjhb "issue+load_store,nothing,memory") 198238423Sjhb 199238423Sjhb(define_insn_reservation "mac_mem" 1 200238423Sjhb (and (eq_attr "pipe_model" "sh4") 201238423Sjhb (eq_attr "type" "mac_mem")) 202238423Sjhb "d_lock,nothing,memory") 203238423Sjhb 204238423Sjhb;; Load Store instructions. 205238423Sjhb;; Group: LS 206238423Sjhb;; Latency: 1 207238423Sjhb;; Issue Rate: 1 208238423Sjhb(define_insn_reservation "sh4_gp_fpul" 1 209238423Sjhb (and (eq_attr "pipe_model" "sh4") 210238423Sjhb (eq_attr "type" "gp_fpul")) 211238423Sjhb "issue+load_store") 212238423Sjhb 213238423Sjhb;; Load Store instructions. 214238423Sjhb;; Group: LS 215238423Sjhb;; Latency: 3 216238423Sjhb;; Issue Rate: 1 217238423Sjhb(define_insn_reservation "sh4_fpul_gp" 3 218238423Sjhb (and (eq_attr "pipe_model" "sh4") 219238423Sjhb (eq_attr "type" "fpul_gp")) 220238423Sjhb "issue+load_store") 221238423Sjhb 222238423Sjhb;; Branch (BF,BF/S,BT,BT/S,BRA) 223238423Sjhb;; Group: BR 224238423Sjhb;; Latency when taken: 2 (or 1) 225238423Sjhb;; Issue Rate: 1 226238423Sjhb;; The latency is 1 when displacement is 0. 227238423Sjhb;; We can't really do much with the latency, even if we could express it, 228238423Sjhb;; but the pairing restrictions are useful to take into account. 229238423Sjhb;; ??? If the branch is likely, we might want to fill the delay slot; 230238423Sjhb;; if the branch is likely, but not very likely, should we pretend to use 231238423Sjhb;; a resource that CO instructions use, to get a pairable delay slot insn? 232238423Sjhb(define_insn_reservation "sh4_branch" 1 233238423Sjhb (and (eq_attr "pipe_model" "sh4") 234238423Sjhb (eq_attr "type" "cbranch,jump")) 235238423Sjhb "issue+pcr_addrcalc") 236238423Sjhb 237238423Sjhb;; Branch Far (JMP,RTS,BRAF) 238238423Sjhb;; Group: CO 239238423Sjhb;; Latency: 3 240238423Sjhb;; Issue Rate: 2 241238423Sjhb;; ??? Scheduling happens before branch shortening, and hence jmp and braf 242238423Sjhb;; can't be distinguished from bra for the "jump" pattern. 243238423Sjhb(define_insn_reservation "sh4_return" 3 244238423Sjhb (and (eq_attr "pipe_model" "sh4") 245238423Sjhb (eq_attr "type" "return,jump_ind")) 246238423Sjhb "d_lock*2") 247238423Sjhb 248238423Sjhb;; RTE 249238423Sjhb;; Group: CO 250238423Sjhb;; Latency: 5 251238423Sjhb;; Issue Rate: 5 252238423Sjhb;; this instruction can be executed in any of the pipelines 253238423Sjhb;; and blocks the pipeline for next 4 stages. 254238423Sjhb(define_insn_reservation "sh4_return_from_exp" 5 255238423Sjhb (and (eq_attr "pipe_model" "sh4") 256238423Sjhb (eq_attr "type" "rte")) 257238423Sjhb "d_lock*5") 258238423Sjhb 259238423Sjhb;; OCBP, OCBWB 260238423Sjhb;; Group: CO 261238423Sjhb;; Latency: 1-5 262238423Sjhb;; Issue Rate: 1 263238423Sjhb;; cwb is used for the sequence 264238423Sjhb;; ocbwb @%0 265238423Sjhb;; extu.w %0,%2 266238423Sjhb;; or %1,%2 267238423Sjhb;; mov.l %0,@%2 268238423Sjhb;; ocbwb on its own would be "d_lock,nothing,memory*5" 269238423Sjhb(define_insn_reservation "ocbwb" 6 270238423Sjhb (and (eq_attr "pipe_model" "sh4") 271238423Sjhb (eq_attr "type" "cwb")) 272238423Sjhb "d_lock*2,(d_lock+memory)*3,issue+load_store+memory,memory*2") 273238423Sjhb 274238423Sjhb;; LDS to PR,JSR 275;; Group: CO 276;; Latency: 3 277;; Issue Rate: 2 278;; The SX stage is blocked for last 2 cycles. 279;; OTOH, the only time that has an effect for insns generated by the compiler 280;; is when lds to PR is followed by sts from PR - and that is highly unlikely - 281;; or when we are doing a function call - and we don't do inter-function 282;; scheduling. For the function call case, it's really best that we end with 283;; something that models an rts. 284(define_insn_reservation "sh4_lds_to_pr" 3 285 (and (eq_attr "pipe_model" "sh4") 286 (eq_attr "type" "prset") ) 287 "d_lock*2") 288 289;; calls introduce a longisch delay that is likely to flush the pipelines 290;; of the caller's instructions. Ordinary functions tend to end with a 291;; load to restore a register (in the delay slot of rts), while sfuncs 292;; tend to end with an EX or MT insn. But that is not actually relevant, 293;; since there are no instructions that contend for memory access early. 294;; We could, of course, provide exact scheduling information for specific 295;; sfuncs, if that should prove useful. 296(define_insn_reservation "sh4_call" 16 297 (and (eq_attr "pipe_model" "sh4") 298 (eq_attr "type" "call,sfunc")) 299 "d_lock*16") 300 301;; LDS.L to PR 302;; Group: CO 303;; Latency: 3 304;; Issue Rate: 2 305;; The SX unit is blocked for last 2 cycles. 306(define_insn_reservation "ldsmem_to_pr" 3 307 (and (eq_attr "pipe_model" "sh4") 308 (eq_attr "type" "pload")) 309 "d_lock*2") 310 311;; STS from PR 312;; Group: CO 313;; Latency: 2 314;; Issue Rate: 2 315;; The SX unit in second and third cycles. 316(define_insn_reservation "sts_from_pr" 2 317 (and (eq_attr "pipe_model" "sh4") 318 (eq_attr "type" "prget")) 319 "d_lock*2") 320 321;; STS.L from PR 322;; Group: CO 323;; Latency: 2 324;; Issue Rate: 2 325(define_insn_reservation "sh4_prstore_mem" 2 326 (and (eq_attr "pipe_model" "sh4") 327 (eq_attr "type" "pstore")) 328 "d_lock*2,nothing,memory") 329 330;; LDS to FPSCR 331;; Group: CO 332;; Latency: 4 333;; Issue Rate: 1 334;; F1 is blocked for last three cycles. 335(define_insn_reservation "fpscr_load" 4 336 (and (eq_attr "pipe_model" "sh4") 337 (eq_attr "type" "gp_fpscr")) 338 "d_lock,nothing,F1*3") 339 340;; LDS.L to FPSCR 341;; Group: CO 342;; Latency: 1 / 4 343;; Latency to update Rn is 1 and latency to update FPSCR is 4 344;; Issue Rate: 1 345;; F1 is blocked for last three cycles. 346(define_insn_reservation "fpscr_load_mem" 4 347 (and (eq_attr "pipe_model" "sh4") 348 (eq_attr "type" "mem_fpscr")) 349 "d_lock,nothing,(F1+memory),F1*2") 350 351 352;; Fixed point multiplication (DMULS.L DMULU.L MUL.L MULS.W,MULU.W) 353;; Group: CO 354;; Latency: 4 / 4 355;; Issue Rate: 2 356(define_insn_reservation "multi" 4 357 (and (eq_attr "pipe_model" "sh4") 358 (eq_attr "type" "smpy,dmpy")) 359 "d_lock,(d_lock+f1_1),(f1_1|f1_2)*3,F2") 360 361;; Fixed STS from, and LDS to MACL / MACH 362;; Group: CO 363;; Latency: 3 364;; Issue Rate: 1 365(define_insn_reservation "sh4_mac_gp" 3 366 (and (eq_attr "pipe_model" "sh4") 367 (eq_attr "type" "mac_gp,gp_mac,mem_mac")) 368 "d_lock") 369 370 371;; Single precision floating point computation FCMP/EQ, 372;; FCMP/GT, FADD, FLOAT, FMAC, FMUL, FSUB, FTRC, FRCHG, FSCHG 373;; Group: FE 374;; Latency: 3/4 375;; Issue Rate: 1 376(define_insn_reservation "fp_arith" 3 377 (and (eq_attr "pipe_model" "sh4") 378 (eq_attr "type" "fp,fp_cmp")) 379 "issue,F01,F2") 380 381;; We don't model the resource usage of this exactly because that would 382;; introduce a bogus latency. 383(define_insn_reservation "sh4_fpscr_toggle" 1 384 (and (eq_attr "pipe_model" "sh4") 385 (eq_attr "type" "fpscr_toggle")) 386 "issue") 387 388(define_insn_reservation "fp_arith_ftrc" 3 389 (and (eq_attr "pipe_model" "sh4") 390 (eq_attr "type" "ftrc_s")) 391 "issue,F01,F2") 392 393(define_bypass 1 "fp_arith_ftrc" "sh4_fpul_gp") 394 395;; Single Precision FDIV/SQRT 396;; Group: FE 397;; Latency: 12/13 (FDIV); 11/12 (FSQRT) 398;; Issue Rate: 1 399;; We describe fdiv here; fsqrt is actually one cycle faster. 400(define_insn_reservation "fp_div" 12 401 (and (eq_attr "pipe_model" "sh4") 402 (eq_attr "type" "fdiv")) 403 "issue,F01+F3,F2+F3,F3*7,F1+F3,F2") 404 405;; Double Precision floating point computation 406;; (FCNVDS, FCNVSD, FLOAT, FTRC) 407;; Group: FE 408;; Latency: (3,4)/5 409;; Issue Rate: 1 410(define_insn_reservation "dp_float" 4 411 (and (eq_attr "pipe_model" "sh4") 412 (eq_attr "type" "dfp_conv")) 413 "issue,F01,F1+F2,F2") 414 415;; Double-precision floating-point (FADD,FMUL,FSUB) 416;; Group: FE 417;; Latency: (7,8)/9 418;; Issue Rate: 1 419(define_insn_reservation "fp_double_arith" 8 420 (and (eq_attr "pipe_model" "sh4") 421 (eq_attr "type" "dfp_arith,dfp_mul")) 422 "issue,F01,F1+F2,fpu*4,F2") 423 424;; Double-precision FCMP (FCMP/EQ,FCMP/GT) 425;; Group: CO 426;; Latency: 3/5 427;; Issue Rate: 2 428(define_insn_reservation "fp_double_cmp" 3 429 (and (eq_attr "pipe_model" "sh4") 430 (eq_attr "type" "dfp_cmp")) 431 "d_lock,(d_lock+F01),F1+F2,F2") 432 433;; Double precision FDIV/SQRT 434;; Group: FE 435;; Latency: (24,25)/26 436;; Issue Rate: 1 437(define_insn_reservation "dp_div" 25 438 (and (eq_attr "pipe_model" "sh4") 439 (eq_attr "type" "dfdiv")) 440 "issue,F01+F3,F1+F2+F3,F2+F3,F3*16,F1+F3,(fpu+F3)*2,F2") 441 442 443;; Use the branch-not-taken case to model arith3 insns. For the branch taken 444;; case, we'd get a d_lock instead of issue at the end. 445(define_insn_reservation "arith3" 3 446 (and (eq_attr "pipe_model" "sh4") 447 (eq_attr "type" "arith3")) 448 "issue,d_lock+pcr_addrcalc,issue") 449 450;; arith3b insns schedule the same no matter if the branch is taken or not. 451(define_insn_reservation "arith3b" 2 452 (and (eq_attr "pipe_model" "sh4") 453 (eq_attr "type" "arith3")) 454 "issue,d_lock+pcr_addrcalc") 455