public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: Hongtao Liu <crazylht@gmail.com>,
	Haochen Jiang <haochen.jiang@intel.com>,
	gcc-patches@gcc.gnu.org,  hongtao.liu@intel.com,
	ubizjak@gmail.com
Subject: Re: [RFC] Intel AVX10.1 Compiler Design and Support
Date: Tue, 12 Dec 2023 13:14:54 +0100	[thread overview]
Message-ID: <CAFiYyc2_VxNnSnV4J3BxCRc6Q=RQACgFwNVJH-aYkjVZqyF7bQ@mail.gmail.com> (raw)
In-Reply-To: <87cyvbn63u.fsf@oldenburg.str.redhat.com>

On Tue, Dec 12, 2023 at 10:05 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Richard Biener:
>
> > If it were possible I'd axe x86_64-v4.  Maybe we should add a x86_64-v3.5
> > that sits inbetween v3 and v4, offering AVX512 but restricted to 256bit
> > (and obviously not requiring more of the AVX512 features that v4
> > requires).
>
> As far as I understand it, GCC's Intel tuning for AVX-512 is leaning
> heavily towards 256 bit vector length anyway.

Indeed it does, enabling avx256_optimal everywhere, but enabling
512bit moves on Sapphire Rapids (and not Granite Rapids!?).

>  That's not true for the
> default tuning for -march=x86-64-v4, though, it prefers 512 bit vectors.
> I've seen third-party reports that AMD Zen 4 does better in some ways
> with 512 bit vectors than with 256 bit vectors (despite its 256-bit-wide
> execution ports), but I have not tried to verify these observations.
> Still, this suggests that restricting a post-x86-64-v3 level to 256 bit
> vectors may not be an easy decision.

The corner Intel painted itself to be in is that their small cores on the
hybrid consumer products only support 128bit native (256bit emulated)
and their data-center "small core" SKU doesn't fare any better there.
That's the reason their marketing invented AVX10 which will allow
the AVX512 ISA play "nice" with a smaller data path (but I'm sure, or
at least I hope, that actual implementations will have a native 256bit
data path and not emulate it via 128bit).

The current problem is that the castrated consumer SKUs cannot use
EVEX at all and in the future will be crippled to 256bits.  So that will
be the common thing to target when targeting EVEX support across
Intel/AMD - use 256bit only.  Note that AVX10 excludes Zen4 which
lacks support for two niche AVX512 ISA extensions.

> On the other hand, a new EVEX-capable level might bring earlier adoption
> of EVEX capabilities to AMD CPUs, which still should be an improvement
> over AVX2.  This could benefit AMD as well.  So I would really like to
> see some AMD feedback here.
>
> There's also the matter that time scales for EVEX adoption are so long
> that by then, Intel CPUs may end up supporting and preferring 512 bit
> vectors again.

True, there isn't even widespread VEX adoption yet ... and now there's
APX as the next best thing to target.

That said, my main point was that x86-64-v4 is "broken" as it appears
as a dead end - AVX512 is no more, the future is AVX10, but yet we have
to define x86-64-v5 as something that includes x86-64-v4.

So, can we un-do x86-64-v4?

Richard.

> Thanks,
> Florian
>

  reply	other threads:[~2023-12-12 12:16 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-10  1:41 Haochen Jiang
2023-11-10  1:41 ` [PATCH] Initial support for AVX10.1 Haochen Jiang
2023-11-20  6:34   ` Hongtao Liu
2023-11-10 10:15 ` [RFC] Intel AVX10.1 Compiler Design and Support Richard Biener
2023-11-13  7:07   ` Hongtao Liu
2023-11-13 11:25     ` Richard Biener
2023-11-14  2:40       ` Hongtao Liu
2023-11-14  6:25         ` Jiang, Haochen
2023-12-12  9:05       ` Florian Weimer
2023-12-12 12:14         ` Richard Biener [this message]
2023-12-13  2:12           ` Jiang, Haochen

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='CAFiYyc2_VxNnSnV4J3BxCRc6Q=RQACgFwNVJH-aYkjVZqyF7bQ@mail.gmail.com' \
    --to=richard.guenther@gmail.com \
    --cc=crazylht@gmail.com \
    --cc=fweimer@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=haochen.jiang@intel.com \
    --cc=hongtao.liu@intel.com \
    --cc=ubizjak@gmail.com \
    /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).