public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Jan Hubička" <honza.hubicka@gmail.com>
To: Alexander Monakov <amonakov@ispras.ru>
Cc: "Kumar, Venkataramanan" <Venkataramanan.Kumar@amd.com>,
	 "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
	"Joshi, Tejas Sanjay" <TejasSanjay.Joshi@amd.com>
Subject: Re: [PATCH 2/2] i386: correct x87&SSE multiplication modeling in znver.md
Date: Wed, 16 Nov 2022 14:28:04 +0100	[thread overview]
Message-ID: <CAJf+eje2iwb3N7DXh3WiqWNLtymNm7Hm1MO59hTEi1C6NYephw@mail.gmail.com> (raw)
In-Reply-To: <50d58d4c-3f13-a4c1-ea7a-2cc40761bb1@ispras.ru>

[-- Attachment #1: Type: text/plain, Size: 2762 bytes --]

On Wed, Nov 16, 2022 at 2:13 PM Alexander Monakov <amonakov@ispras.ru>
wrote:

>
> On Wed, 16 Nov 2022, Jan Hubička wrote:
>
> > This looks really promising.  I will experiment with the patch for
> separate
> > znver3 model, but I think we should be able to keep
> > them unified and hopefully get both less code duplicatoin and table
> sizes.
>
> Do you mean separate znver4 (not '3') model (i.e. the recent patch by AMD)?
>

Yes. I guess we want to check what variant leads to smaller automaton.  I
would somewhat prefer to keep the models unified since they are quite
similar

> > > znver1 native path is 128  and znver2/3 has 256 bit paths.
> > > We need to split this into two reservations. One for znver1 and the
> other
> > > for znver2/3.
> > >
> >
> > isn't it znver2 for 128 and znver3 for 256?
>
> No, Zen 1 splits AVX256 instructions into pairs of 128-bit uops, Zen 2 and
> Zen 3 have native 256-bit units. Zen 4 again executes AVX512 instructions
> on 256-bit units.
>

Ah, of course.  I mixed things up in my memory. Sorry fro that.

>
> I think a split is not needed because the preceding reservation already
> handles
> znver2 and znver3, we just need to remove them here, like this:
>
> diff --git a/gcc/config/i386/znver.md b/gcc/config/i386/znver.md
> index 882f250f1..16b5afa5d 100644
> --- a/gcc/config/i386/znver.md
> +++ b/gcc/config/i386/znver.md
> @@ -1242,7 +1242,7 @@ (define_insn_reservation "znver1_sseimul" 3
>                          "znver1-direct,znver1-fp0")
>
>  (define_insn_reservation "znver1_sseimul_avx256" 4
> -                        (and (eq_attr "cpu" "znver1,znver2,znver3")
> +                        (and (eq_attr "cpu" "znver1")
>

It should work even without removal since first reservation matches, but
this is quite less confusing indeed.

>                               (and (eq_attr "mode" "OI")
>                                    (and (eq_attr "type" "sseimul")
>                                         (eq_attr "memory" "none"))))
> @@ -1260,7 +1260,7 @@ (define_insn_reservation "znver1_sseimul_load" 10
>                          "znver1-direct,znver1-load,znver1-fp0")
>
>  (define_insn_reservation "znver1_sseimul_avx256_load" 11
> -                        (and (eq_attr "cpu" "znver1,znver2,znver3")
> +                        (and (eq_attr "cpu" "znver1")
>                               (and (eq_attr "mode" "OI")
>                                    (and (eq_attr "type" "sseimul")
>                                         (eq_attr "memory" "load"))))
>
> > The patch looks good.
> > >
> > Patch is OK then :)
>
> For *both* patches in the series?
>

Yes, thanks a lot for looking into this!
Honza

>
> Alexander

  reply	other threads:[~2022-11-16 13:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-01 16:26 [PATCH 0/2] i386: slim down insn-automata [PR 87832] Alexander Monakov
2022-11-01 16:26 ` [PATCH 1/2] i386: correct x87&SSE division modeling in znver.md Alexander Monakov
2022-11-01 16:26 ` [PATCH 2/2] i386: correct x87&SSE multiplication " Alexander Monakov
2022-11-16 11:53   ` Kumar, Venkataramanan
2022-11-16 12:21     ` Jan Hubička
2022-11-16 13:13       ` Alexander Monakov
2022-11-16 13:28         ` Jan Hubička [this message]
2022-11-07 11:27 ` [PATCH 0/2] i386: slim down insn-automata [PR 87832] Alexander Monakov
2022-11-14 11:19   ` Alexander Monakov

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+eje2iwb3N7DXh3WiqWNLtymNm7Hm1MO59hTEi1C6NYephw@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).