From: "Jan Hubička" <honza.hubicka@gmail.com>
To: "Joshi, Tejas Sanjay" <TejasSanjay.Joshi@amd.com>
Cc: Alexander Monakov <amonakov@ispras.ru>,
"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
"Kumar, Venkataramanan" <Venkataramanan.Kumar@amd.com>
Subject: Re: [PATCH][X86_64] Separate znver4 insn reservations from older znvers
Date: Mon, 12 Dec 2022 22:41:23 +0100 [thread overview]
Message-ID: <CAJf+ejcm=cQRsgUwvDt7y-0yw_43gP09f636eoQ674sf7kwsMw@mail.gmail.com> (raw)
In-Reply-To: <DM6PR12MB479566CF7A10C57A983BFC34E3149@DM6PR12MB4795.namprd12.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 35240 bytes --]
> I have addressed all your comments in this revised patch, PFA and inlined
> below.
>
> Is it ok for trunk?
>
> Thanks and Regards,
> Tejas
>
> gcc/ChangeLog:
>
> * gcc/common/config/i386/i386-common.cc (processor_alias_table):
> Use CPU_ZNVER4 for znver4.
> * config/i386/i386.md: Add znver4.md.
> * config/i386/znver4.md: New.
>
Hi,
I went through the patch and compared with Agner's table and have few
comments below.
>
> ---
> gcc/common/config/i386/i386-common.cc | 2 +-
> gcc/config/i386/i386.md | 1 +
> gcc/config/i386/znver4.md | 1027 +++++++++++++++++++++++++
> 3 files changed, 1029 insertions(+), 1 deletion(-)
> create mode 100644 gcc/config/i386/znver4.md
>
> diff --git a/gcc/common/config/i386/i386-common.cc
> b/gcc/common/config/i386/i386-common.cc
> index 6ce2a588adc..6d941642911 100644
> --- a/gcc/common/config/i386/i386-common.cc
> +++ b/gcc/common/config/i386/i386-common.cc
> @@ -2207,7 +2207,7 @@ const pta processor_alias_table[] =
> {"znver3", PROCESSOR_ZNVER3, CPU_ZNVER3,
> PTA_ZNVER3,
> M_CPU_SUBTYPE (AMDFAM19H_ZNVER3), P_PROC_AVX2},
> - {"znver4", PROCESSOR_ZNVER4, CPU_ZNVER3,
> + {"znver4", PROCESSOR_ZNVER4, CPU_ZNVER4,
> PTA_ZNVER4,
> M_CPU_SUBTYPE (AMDFAM19H_ZNVER4), P_PROC_AVX512F},
> {"btver1", PROCESSOR_BTVER1, CPU_GENERIC,
> diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
> index 01faa911b77..ebb4eec1961 100644
> --- a/gcc/config/i386/i386.md
> +++ b/gcc/config/i386/i386.md
> @@ -1318,6 +1318,7 @@
> (include "bdver3.md")
> (include "btver2.md")
> (include "znver.md")
> +(include "znver4.md")
> (include "geode.md")
> (include "atom.md")
> (include "slm.md")
> diff --git a/gcc/config/i386/znver4.md b/gcc/config/i386/znver4.md
> new file mode 100644
> index 00000000000..9d52dc517f5
> --- /dev/null
> +++ b/gcc/config/i386/znver4.md
> @@ -0,0 +1,1027 @@
> +;; Copyright (C) 2012-2022 Free Software Foundation, Inc.
> +;;
> +;; This file is part of GCC.
> +;;
> +;; GCC is free software; you can redistribute it and/or modify
> +;; it under the terms of the GNU General Public License as published by
> +;; the Free Software Foundation; either version 3, or (at your option)
> +;; any later version.
> +;;
> +;; GCC is distributed in the hope that it will be useful,
> +;; but WITHOUT ANY WARRANTY; without even the implied warranty of
> +;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +;; GNU General Public License for more details.
> +;;
> +;; You should have received a copy of the GNU General Public License
> +;; along with GCC; see the file COPYING3. If not see
> +;; <http://www.gnu.org/licenses/>.
> +;;
> +
> +
> +(define_attr "znver4_decode" "direct,vector,double"
> + (const_string "direct"))
> +
> +;; AMD znver4 Scheduling
> +;; Modeling automatons for zen decoders, integer execution pipes,
> +;; AGU pipes, branch, floating point execution and fp store units.
> +(define_automaton "znver4, znver4_ieu, znver4_idiv, znver4_fdiv,
> znver4_agu, znver4_bru, znver4_fpu, znver4_fp_store")
> +
> +;; Decoders unit has 4 decoders and all of them can decode fast path
> +;; and vector type instructions.
> +(define_cpu_unit "znver4-decode0" "znver4")
> +(define_cpu_unit "znver4-decode1" "znver4")
> +(define_cpu_unit "znver4-decode2" "znver4")
> +(define_cpu_unit "znver4-decode3" "znver4")
> +
> +;; Currently blocking all decoders for vector path instructions as
> +;; they are dispatched separetely as microcode sequence.
> +(define_reservation "znver4-vector"
> "znver4-decode0+znver4-decode1+znver4-decode2+znver4-decode3")
> +
> +;; Direct instructions can be issued to any of the four decoders.
> +(define_reservation "znver4-direct"
> "znver4-decode0|znver4-decode1|znver4-decode2|znver4-decode3")
> +
> +;; Fix me: Need to revisit this later to simulate fast path double
> behavior.
> +(define_reservation "znver4-double" "znver4-direct")
> +
> +
> +;; Integer unit 4 ALU pipes.
> +(define_cpu_unit "znver4-ieu0" "znver4_ieu")
> +(define_cpu_unit "znver4-ieu1" "znver4_ieu")
> +(define_cpu_unit "znver4-ieu2" "znver4_ieu")
> +(define_cpu_unit "znver4-ieu3" "znver4_ieu")
> +(define_reservation "znver4-ieu"
> "znver4-ieu0|znver4-ieu1|znver4-ieu2|znver4-ieu3")
> +
> +;; 3 AGU pipes in znver4
> +(define_cpu_unit "znver4-agu0" "znver4_agu")
> +(define_cpu_unit "znver4-agu1" "znver4_agu")
> +(define_cpu_unit "znver4-agu2" "znver4_agu")
> +(define_reservation "znver4-agu-reserve"
> "znver4-agu0|znver4-agu1|znver4-agu2")
> +
> +;; Load is 4 cycles. We do not model reservation of load unit.
> +(define_reservation "znver4-load" "znver4-agu-reserve")
> +(define_reservation "znver4-store" "znver4-agu-reserve")
> +
> +;; vectorpath (microcoded) instructions are single issue instructions.
> +;; So, they occupy all the integer units.
> +(define_reservation "znver4-ivector" "znver4-ieu0+znver4-ieu1
> + +znver4-ieu2+znver4-ieu3
> +
> +znver4-agu0+znver4-agu1+znver4-agu2")
> +
> +;; Floating point unit 4 FP pipes.
> +(define_cpu_unit "znver4-fpu0" "znver4_fpu")
> +(define_cpu_unit "znver4-fpu1" "znver4_fpu")
> +(define_cpu_unit "znver4-fpu2" "znver4_fpu")
> +(define_cpu_unit "znver4-fpu3" "znver4_fpu")
> +
> +(define_reservation "znver4-fpu"
> "znver4-fpu0|znver4-fpu1|znver4-fpu2|znver4-fpu3")
> +
> +(define_reservation "znver4-fvector" "znver4-fpu0+znver4-fpu1
> + +znver4-fpu2+znver4-fpu3
> +
> +znver4-agu0+znver4-agu1+znver4-agu2")
> +
> +;; DIV units
> +(define_cpu_unit "znver4-idiv" "znver4_idiv")
> +(define_cpu_unit "znver4-fdiv" "znver4_fdiv")
> +
> +;; znver4 has a separate branch unit.
> +(define_cpu_unit "znver4-bru" "znver4_bru")
>
So this unit is new since znver2 model. Rest of stuff above is the same,
right?
> +
> +;; Separate fp store and fp-to-int store. Although there are 2 store
> pipes, the
> +;; throughput is limited to only one per cycle.
> +(define_cpu_unit "znver4-fp-store" "znver4_fp_store")
> +
> +;; Call Instruction
> +(define_insn_reservation "znver4_call" 1
> + (and (eq_attr "cpu" "znver4")
> + (eq_attr "type" "call,callv"))
> +
> "znver4-double,znver4-ieu0|znver4-bru,znver4-store")
>
Perhaps this should be znver4-ieu0+znver4-bru to model the fact that call
uses the branch unit?
Also using | for things from different units is not really working as
expected since in independent
automatons we will end up chosing to not reserve anything.
> +
> +;; Push Instruction
> +(define_insn_reservation "znver4_push" 1
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "push")
> + (eq_attr "memory" "store")))
> + "znver4-direct,znver4-store")
> +
> +(define_insn_reservation "znver4_push_load" 5
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "push")
> + (eq_attr "memory" "both")))
> + "znver4-direct,znver4-load,znver4-store")
>
Here we have 5 cycles instead of 4 for push. However reservations wise we do
cycle 0 - direct
cycle 1 - load
cycle 2 - store
and nothing in remaining two cycles.
> +
> +;; Pop instruction
> +(define_insn_reservation "znver4_pop" 1
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "pop")
> + (eq_attr "memory" "load")))
> + "znver4-direct,znver4-load")
> +
> +(define_insn_reservation "znver4_pop_mem" 5
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "pop")
> + (eq_attr "memory" "both")))
> + "znver4-direct,znver4-load,znver4-store")
>
Similar situation here.
I remember that at znver1 time I had problem with defining load as 4-cycle
operation since the model got too large.
This is probably artifact of that. I wonder if with the separation of
division from the main model this still causes
troubles...
> +
> +;; Leave
> +(define_insn_reservation "znver4_leave" 1
> + (and (eq_attr "cpu" "znver4")
> + (eq_attr "type" "leave"))
> + "znver4-double,znver4-ieu,znver4-store")
> +
> +;; Integer Instructions or General instructions
> +;; Multiplications
> +(define_insn_reservation "znver4_imul" 3
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "imul")
> + (and (eq_attr "mode" "QI,HI,SI")
> + (eq_attr "memory" "none"))))
> + "znver4-direct,znver4-ieu1")
> +
> +(define_insn_reservation "znver4_imul_DI" 4
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "imul")
> + (and (eq_attr "mode" "DI")
> + (eq_attr "memory" "none"))))
> + "znver4-direct,znver4-ieu1")
>
Note that Agner Fog's tables claims znver4 imul to be still 3 cycles even
for 64bit..
+
>
> +(define_insn_reservation "znver4_imov_direct_store" 1
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "imov")
> + (eq_attr "memory" "store")))
> + "znver4-direct,znver4-ieu,znver4-store")
> +
> +(define_insn_reservation "znver4_imov_load_double_store" 4
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "znver1_decode" "double")
> + (and (eq_attr "type" "imovx")
> + (eq_attr "memory" "store"))))
> +
> "znver4-double,znver4-load,znver4-ieu,znver4-store")
> +
> +(define_insn_reservation "znver4_imov_load_direct_store" 4
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "imov")
> + (eq_attr "memory" "store")))
> +
> "znver4-direct,znver4-load,znver4-ieu,znver4-store")
>
I wonder why znver4-load is here when memory is "store"?
> +
> +;; INTEGER/GENERAL Instructions
> +(define_insn_reservation "znver4_insn2_load" 5
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "icmov,setcc")
> + (eq_attr "memory" "load")))
> +
> "znver4-direct,znver4-load,znver4-ieu0|znver4-ieu3")
> +
> +
> +(define_insn_reservation "znver4_insn2_store" 1
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "icmov,setcc")
> + (eq_attr "memory" "load")))
> +
> "znver4-direct,znver4-ieu0|znver4-ieu3,znver4-store")
>
This looks like bug to me that is cut&pasted few times. Stores should test
memory for "store" otherwise it is identical
to reservation above.
> +
> +;; Other vector type
> +(define_insn_reservation "znver4_ieu_vector" 5
> + (and (eq_attr "cpu" "znver4")
> + (eq_attr "type" "other,multi"))
> + "znver4-vector,znver4-ivector")
>
znvermodel tests also for str. Store and both is handled earlier but what
about loads?
> +
> +;; alu1 instructions
> +(define_insn_reservation "znver4_alu1_vector" 3
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "znver1_decode" "vector")
> + (and (eq_attr "type" "alu1")
> + (eq_attr "memory"
> "none,unknown"))))
> + "znver4-vector,znver4-ivector")
> +
> +(define_insn_reservation "znver4_alu1_direct" 1
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "znver1_decode" "direct")
> + (and (eq_attr "type" "alu1")
> + (eq_attr "memory"
> "none,unknown"))))
> + "znver4-direct,znver4-ieu")
> +
> +;; Branches
> +(define_insn_reservation "znver4_branch" 1
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "ibr")
> + (eq_attr "memory" "none")))
> + "znver4-direct,znver4-ieu0|znver4-bru")
>
Probably + insead of |
> +
> +(define_insn_reservation "znver4_branch_mem" 5
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "ibr")
> + (eq_attr "memory" "load")))
> + "znver4-vector,znver4-ivector")
>
No bru use here?
> +
> +;; LEA instruction with simple addressing
> +(define_insn_reservation "znver4_lea" 1
> + (and (eq_attr "cpu" "znver4")
> + (eq_attr "type" "lea"))
> + "znver4-direct,znver4-ieu")
> +
> +;; Floating Point
> +;; FP movs
> +(define_insn_reservation "znver4_fp_cmov" 6
> + (and (eq_attr "cpu" "znver4")
> + (eq_attr "type" "fcmov"))
> + "znver4-vector,znver4-fvector")
>
Agner Fog claims 4 cycles here.
> +(define_insn_reservation "znver4_fp_mov_direct_load" 8
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "znver1_decode" "direct")
> + (and (eq_attr "type" "fmov")
> + (eq_attr "memory" "load"))))
> + "znver4-direct,znver4-load,znver4-fpu1")
>
7 cycles in Agner Fog's manual
> +
> +(define_insn_reservation "znver4_fp_mov_direct_store" 5
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "znver1_decode" "direct")
> + (and (eq_attr "type" "fmov")
> + (eq_attr "memory" "store"))))
> + "znver4-direct,znver4-fpu1,znver4-fp-store")
>
6 by Agner Fog
> +
> +(define_insn_reservation "znver4_fp_mov_double" 5
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "znver1_decode" "double")
> + (and (eq_attr "type" "fmov")
> + (eq_attr "memory" "none"))))
> + "znver4-double,znver4-fpu1,znver4-fp-store")
>
I wonder what this matches.
> +
> +(define_insn_reservation "znver4_fp_mov_double_load" 12
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "znver1_decode" "double")
> + (and (eq_attr "type" "fmov")
> + (eq_attr "memory" "load"))))
> +
> "znver4-double,znver4-load,znver4-fpu1,znver4-fp-store")
>
It seems that fild is modeled as fmov and double decode, but Agner Fog
claims it is single decode with latency 13.
> +;; FADD, FSUB, FMUL
> +(define_insn_reservation "znver4_fp_op_mul" 6
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "fop,fmul")
> + (eq_attr "memory" "none")))
> + "znver4-direct,znver4-fpu0")
>
7 by Agner Fog
> +
> +;; AVX instructions
> +(define_insn_reservation "znver4_sse_log" 1
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "sselog")
> + (and (eq_attr "mode"
> "V4SF,V8SF,V2DF,V4DF,QI,HI,SI,DI,TI,OI")
> + (eq_attr "memory" "none"))))
> + "znver4-direct,znver4-fpu")
> +
> +(define_insn_reservation "znver4_sse_log_load" 8
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "sselog")
> + (and (eq_attr "mode"
> "V4SF,V8SF,V2DF,V4DF,QI,HI,SI,DI,TI,OI")
> + (eq_attr "memory" "load"))))
> + "znver4-direct,znver4-load,znver4-fpu")
>
Agner fog lists sse load as 5 cycles, so I wonder if it is right for
operation to be 8 instead of 6?
> +
> +(define_insn_reservation "znver4_sse_log1" 1
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "sselog1")
> + (and (eq_attr "mode"
> "V4SF,V8SF,V2DF,V4DF,QI,HI,SI,DI,TI,OI")
> + (eq_attr "memory" "none"))))
> +
> "znver4-direct,znver4-fpu1|znver4-fpu2,znver4-fp-store")
>
So logical operations take store unit even if they are not storing?
> +
> +(define_insn_reservation "znver4_sse_log1_load" 8
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "sselog1")
> + (and (eq_attr "mode"
> "V4SF,V8SF,V2DF,V4DF,QI,HI,SI,DI,TI,OI")
> + (eq_attr "memory" "load"))))
> +
> "znver4-direct,znver4-load,znver4-fpu1|znver4-fpu2,znver4-fp-store")
> +
> +(define_insn_reservation "znver4_sse_comi" 1
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "ssecomi")
> + (eq_attr "memory" "none")))
> +
> "znver4-double,znver4-fpu2|znver4-fpu3,znver4-fp-store")
> +
> +(define_insn_reservation "znver4_sse_comi_load" 8
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "ssecomi")
> + (eq_attr "memory" "load")))
> +
> "znver4-double,znver4-load,znver4-fpu2|znver4-fpu3,znver4-fp-store")
> +
> +(define_insn_reservation "znver4_sse_test" 1
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "prefix_extra" "1")
> + (and (eq_attr "type" "ssecomi")
> + (eq_attr "memory" "none"))))
> + "znver4-direct,znver4-fpu1|znver4-fpu2")
> +
> +(define_insn_reservation "znver4_sse_test_load" 8
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "prefix_extra" "1")
> + (and (eq_attr "type" "ssecomi")
> + (eq_attr "memory" "load"))))
> +
> "znver4-direct,znver4-load,znver4-fpu1|znver4-fpu2")
> +
> +(define_insn_reservation "znver4_sse_imul" 3
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "sseimul")
> + (and (eq_attr "mode"
> "QI,HI,SI,DI,TI,OI")
> + (eq_attr "memory" "none"))))
> + "znver4-direct,znver4-fpu0|znver4-fpu3")
> +
> +(define_insn_reservation "znver4_sse_imul_load" 10
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "sseimul")
> + (and (eq_attr "mode"
> "QI,HI,SI,DI,TI,OI")
> + (eq_attr "memory" "load"))))
> +
> "znver4-direct,znver4-load,znver4-fpu0|znver4-fpu1")
> +
> +(define_insn_reservation "znver4_sse_mov" 2
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "ssemov")
> + (and (eq_attr "mode"
> "QI,HI,SI,DI,TI,OI")
> + (eq_attr "memory" "none"))))
> + "znver4-direct,znver4-fpu1|znver4-fpu2")
>
I think this is copied from znver1 table. It should be 1 cycle and often 0
if renaming happens?
> +
> +(define_insn_reservation "znver4_sse_mov_load" 9
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "ssemov")
> + (and (eq_attr "mode"
> "QI,HI,SI,DI,TI,OI")
> + (eq_attr "memory" "load"))))
> +
> "znver4-direct,znver4-load,znver4-fpu1|znver4-fpu2")
>
5 cycles Agner Fog
> +
> +(define_insn_reservation "znver4_sse_mov_store" 5
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "ssemov")
> + (and (eq_attr "mode"
> "QI,HI,SI,DI,TI,OI")
> + (eq_attr "memory" "store"))))
> +
> "znver4-direct,znver4-fpu1|znver4-fpu2,znver4-fp-store")
>
We model other stores as 1 cycle operation, why you use 5 here?
Also it seems that normal store is 1 op, so why it needs fpu?
> +(define_insn_reservation "znver4_sse_add1" 6
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "sseadd1")
> + (and (eq_attr "mode"
> "V8SF,V4DF,V4SF,V2DF,V2SF,V1DF,SF")
> + (eq_attr "memory" "none"))))
> + "znver4-vector,znver4-fvector")
>
This seems to match hadd that is listed as 4 cycles in Agner Fog.
Why it is vector decode?
> +
> +(define_insn_reservation "znver4_sse_add1_load" 13
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "sseadd1")
> + (and (eq_attr "mode"
> "V8SF,V4DF,V4SF,V2DF,V2SF,V1DF,SF")
> + (eq_attr "memory" "load"))))
> + "znver4-vector,znver4-load,znver4-fvector")
>
Similarly here.
> +(define_insn_reservation "znver4_sse_cmp_avx" 3
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "ssecmp,ssecomi")
> + (and (eq_attr "mode"
> "V4SF,V2DF,V2SF,V1DF,SF,QI,HI,SI,DI,TI")
> + (eq_attr "memory" "none"))))
> + "znver4-direct,znver4-fpu0|znver4-fpu1")
> +
> +(define_insn_reservation "znver4_sse_cmp_avx_load" 10
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "ssecmp,ssecomi")
> + (and (eq_attr "mode"
> "V4SF,V2DF,V2SF,V1DF,SF,QI,HI,SI,DI,TI")
> + (eq_attr "memory" "load"))))
> +
> "znver4-direct,znver4-load,znver4-fpu0|znver4-fpu1")
> +
> +(define_insn_reservation "znver4_sse_cmp_avx2" 4
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "ssecmp,ssecomi")
> + (and (eq_attr "mode" "V8SF,V4DF,OI")
> + (eq_attr "memory" "none"))))
> + "znver4-direct,znver4-fpu0|znver4-fpu1")
>
Is there really differnece between 128bit and 256bit here?
+;; AVX512 instructions
>
> +(define_insn_reservation "znver4_sse_log_evex" 1
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "sselog")
> + (and (eq_attr "mode" "V16SF,V8DF,XI")
> + (eq_attr "memory" "none"))))
> +
> "znver4-direct,znver4-fpu0*2|znver4-fpu1*2|znver4-fpu2*2|znver4-fpu3*2")
>
I think the instruction does two operaitos in parallel so
(znver4-fpu0+znver4-fpu1)|(znver4-fpu1+znver4-fpu2)|(znver4-fpu0+znver4-fpu2)
> +
> +(define_insn_reservation "znver4_sse_log_evex_load" 8
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "sselog")
> + (and (eq_attr "mode" "V16SF,V8DF,XI")
> + (eq_attr "memory" "load"))))
> +
> "znver4-direct,znver4-load,znver4-fpu0*2|znver4-fpu1*2|znver4-fpu2*2|znver4-fpu3*2")
> +
> +(define_insn_reservation "znver4_sse_log1_evex" 1
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "sselog1")
> + (and (eq_attr "mode" "V16SF,V8DF,XI")
> + (eq_attr "memory" "none"))))
> +
> "znver4-direct,znver4-fpu1*2|znver4-fpu2*2,znver4-fp-store")
> +
> +(define_insn_reservation "znver4_sse_log1_evex_load" 8
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "sselog1")
> + (and (eq_attr "mode" "V16SF,V8DF,XI")
> + (eq_attr "memory" "load"))))
> +
> "znver4-direct,znver4-load,znver4-fpu1*2|znver4-fpu2*2,znver4-fp-store")
> +
> +(define_insn_reservation "znver4_sse_mul_evex" 3
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "ssemul")
> + (and (eq_attr "mode" "V16SF,V8DF")
> + (eq_attr "memory" "none"))))
> + "znver4-direct,znver4-fpu0*2|znver4-fpu1*2")
> +
> +(define_insn_reservation "znver4_sse_mul_evex_load" 10
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "ssemul")
> + (and (eq_attr "mode" "V16SF,V8DF")
> + (eq_attr "memory" "load"))))
> +
> "znver4-direct,znver4-load,znver4-fpu0*2|znver4-fpu1*2")
> +
> +(define_insn_reservation "znver4_sse_imul_evex" 3
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "sseimul")
> + (and (eq_attr "mode" "XI")
> + (eq_attr "memory" "none"))))
> + "znver4-direct,znver4-fpu0*2|znver4-fpu3*2")
> +
> +(define_insn_reservation "znver4_sse_imul_evex_load" 10
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "sseimul")
> + (and (eq_attr "mode" "XI")
> + (eq_attr "memory" "load"))))
> +
> "znver4-direct,znver4-load,znver4-fpu0*2|znver4-fpu1*2")
> +
> +(define_insn_reservation "znver4_sse_mov_evex" 4
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "ssemov")
> + (and (eq_attr "mode" "XI")
> + (eq_attr "memory" "none"))))
> + "znver4-direct,znver4-fpu1*2|znver4-fpu2*2")
> +
> +(define_insn_reservation "znver4_sse_mov_evex_load" 11
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "ssemov")
> + (and (eq_attr "mode" "XI")
> + (eq_attr "memory" "load"))))
> +
> "znver4-direct,znver4-load,znver4-fpu1*2|znver4-fpu2*2")
> +
> +(define_insn_reservation "znver4_sse_mov_evex_store" 5
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "ssemov")
> + (and (eq_attr "mode" "XI")
> + (eq_attr "memory" "store"))))
> +
> "znver4-direct,znver4-fpu1*2|znver4-fpu2*2,znver4-fp-store")
> +
> +(define_insn_reservation "znver4_sse_add_evex" 3
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "sseadd")
> + (and (eq_attr "mode" "V16SF,V8DF")
> + (eq_attr "memory" "none"))))
> + "znver4-direct,znver4-fpu2*2|znver4-fpu3*2")
> +
> +(define_insn_reservation "znver4_sse_add_evex_load" 10
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "sseadd")
> + (and (eq_attr "mode" "V16SF,V8DF")
> + (eq_attr "memory" "load"))))
> +
> "znver4-direct,znver4-load,znver4-fpu2*2|znver4-fpu3*2")
> +
> +(define_insn_reservation "znver4_sse_iadd_evex" 1
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "sseiadd")
> + (and (eq_attr "mode" "XI")
> + (eq_attr "memory" "none"))))
> +
> "znver4-direct,znver4-fpu0*2|znver4-fpu1*2|znver4-fpu2*2|znver4-fpu3*2")
> +
> +(define_insn_reservation "znver4_sse_iadd_evex_load" 8
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "sseiadd")
> + (and (eq_attr "mode" "XI")
> + (eq_attr "memory" "load"))))
> +
> "znver4-direct,znver4-load,znver4-fpu0*2|znver4-fpu1*2|znver4-fpu2*2|znver4-fpu3*2")
> +
> +(define_insn_reservation "znver4_sse_div_pd_evex" 13
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "ssediv")
> + (and (eq_attr "mode" "V8DF")
> + (eq_attr "memory" "none"))))
> + "znver4-direct,znver4-fdiv*9")
> +
> +(define_insn_reservation "znver4_sse_div_ps_evex" 10
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "ssediv")
> + (and (eq_attr "mode" "V16SF")
> + (eq_attr "memory" "none"))))
> + "znver4-direct,znver4-fdiv*6")
> +
> +(define_insn_reservation "znver4_sse_div_pd_evex_load" 20
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "ssediv")
> + (and (eq_attr "mode" "V8DF")
> + (eq_attr "memory" "load"))))
> + "znver4-direct,znver4-load,znver4-fdiv*9")
> +
> +(define_insn_reservation "znver4_sse_div_ps_evex_load" 17
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "ssediv")
> + (and (eq_attr "mode" "V16SF")
> + (eq_attr "memory" "load"))))
> + "znver4-direct,znver4-load,znver4-fdiv*6")
> +
> +(define_insn_reservation "znver4_sse_cmp_avx512" 5
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "ssecmp,ssecomi")
> + (and (eq_attr "mode" "V16SF,V8DF,XI")
> + (eq_attr "memory" "none"))))
> + "znver4-direct,znver4-fpu0*2|znver4-fpu1*2")
> +
> +(define_insn_reservation "znver4_sse_cmp_avx512_load" 12
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "ssecmp,ssecomi")
> + (and (eq_attr "mode" "V16SF,V8DF,XI")
> + (eq_attr "memory" "load"))))
> +
> "znver4-direct,znver4-load,znver4-fpu0*2|znver4-fpu1*2")
> +
> +(define_insn_reservation "znver4_sse_cvt_evex" 6
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "ssecvt")
> + (and (eq_attr "mode" "V16SF,V8DF")
> + (eq_attr "memory" "none"))))
> +
> "znver4-direct,znver4-fpu1*2|znver4-fpu2*2,znver4-fpu2*2|znver4-fpu3*2")
> +
> +(define_insn_reservation "znver4_sse_cvt_evex_load" 13
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "ssecvt")
> + (and (eq_attr "mode" "V16SF,V8DF")
> + (eq_attr "memory" "load"))))
> +
> "znver4-direct,znver4-load,znver4-fpu1*2|znver4-fpu2*2,znver4-fpu2*2|znver4-fpu3*2")
> +
> +(define_insn_reservation "znver4_sse_shuf_evex" 1
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "sseshuf")
> + (and (eq_attr "mode" "V16SF,V8DF")
> + (eq_attr "memory" "none"))))
> +
> "znver4-direct,znver4-fpu0*2|znver4-fpu1*2|znver4-fpu2*2|znver4-fpu3*2")
> +
> +(define_insn_reservation "znver4_sse_shuf_evex_load" 8
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "sseshuf")
> + (and (eq_attr "mode" "V16SF,V8DF")
> + (eq_attr "memory" "load"))))
> +
> "znver4-direct,znver4-load,znver4-fpu0*2|znver4-fpu1*2|znver4-fpu2*2|znver4-fpu3*2")
> +
> +(define_insn_reservation "znver4_sse_ishuf_evex" 4
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "sseshuf")
> + (and (eq_attr "mode" "XI")
> + (eq_attr "memory" "none"))))
> + "znver4-direct,znver4-fpu1*2|znver4-fpu2*2")
> +
> +(define_insn_reservation "znver4_sse_ishuf_evex_load" 11
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "sseshuf")
> + (and (eq_attr "mode" "XI")
> + (eq_attr "memory" "load"))))
> +
> "znver4-direct,znver4-load,znver4-fpu1*2|znver4-fpu2*2")
> +
> +(define_insn_reservation "znver4_sse_muladd" 4
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "ssemuladd")
> + (eq_attr "memory" "none")))
> + "znver4-direct,znver4-fpu0*2|znver4-fpu1*2")
> +
> +(define_insn_reservation "znver4_sse_muladd_load" 11
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "sseshuf")
> + (eq_attr "memory" "load")))
> +
> "znver4-direct,znver4-load,znver4-fpu0*2|znver4-fpu1*2")
> +
> +;; AVX512 mask instructions
> +
> +(define_insn_reservation "znver4_sse_mskmov" 2
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "mskmov")
> + (eq_attr "memory" "none")))
> + "znver4-direct,znver4-fpu0*2|znver4-fpu1*2")
> +
> +(define_insn_reservation "znver4_sse_msklog" 1
> + (and (eq_attr "cpu" "znver4")
> + (and (eq_attr "type" "msklog")
> + (eq_attr "memory" "none")))
> + "znver4-direct,znver4-fpu2*2|znver4-fpu3*2")
>
Honza
next prev parent reply other threads:[~2022-12-12 21:41 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-14 16:18 Joshi, Tejas Sanjay
2022-11-14 18:51 ` Alexander Monakov
2022-11-15 12:08 ` Joshi, Tejas Sanjay
2022-11-15 12:51 ` Alexander Monakov
2022-11-21 11:40 ` Joshi, Tejas Sanjay
2022-11-21 15:30 ` Alexander Monakov
2022-12-01 11:28 ` Joshi, Tejas Sanjay
2022-12-01 19:01 ` Alexander Monakov
2022-12-12 21:41 ` Jan Hubička [this message]
2022-12-22 17:34 ` Joshi, Tejas Sanjay
2023-01-03 14:36 ` Jan Hubicka
2023-01-03 14:52 ` Alexander Monakov
2023-01-03 18:28 ` Jan Hubicka
2023-01-05 5:52 ` Joshi, Tejas Sanjay
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJf+ejcm=cQRsgUwvDt7y-0yw_43gP09f636eoQ674sf7kwsMw@mail.gmail.com' \
--to=honza.hubicka@gmail.com \
--cc=TejasSanjay.Joshi@amd.com \
--cc=Venkataramanan.Kumar@amd.com \
--cc=amonakov@ispras.ru \
--cc=gcc-patches@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).