From: Hongtao Liu <crazylht@gmail.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: Haochen Jiang <haochen.jiang@intel.com>,
gcc-patches@gcc.gnu.org, hongtao.liu@intel.com,
ubizjak@gmail.com, Florian Weimer <fweimer@redhat.com>
Subject: Re: [RFC] Intel AVX10.1 Compiler Design and Support
Date: Tue, 14 Nov 2023 10:40:24 +0800 [thread overview]
Message-ID: <CAMZc-bykR4NoXwojHozaOGY4W5LSDiNABui7rd4Dv0GhT5=zSg@mail.gmail.com> (raw)
In-Reply-To: <CAFiYyc06QvUcoMDab8ErV8ZqAfwOhCVOQZfJq2UgcSanNPGxow@mail.gmail.com>
On Mon, Nov 13, 2023 at 7:25 PM Richard Biener
<richard.guenther@gmail.com> wrote:
>
> On Mon, Nov 13, 2023 at 7:58 AM Hongtao Liu <crazylht@gmail.com> wrote:
> >
> > On Fri, Nov 10, 2023 at 6:15 PM Richard Biener
> > <richard.guenther@gmail.com> wrote:
> > >
> > > On Fri, Nov 10, 2023 at 2:42 AM Haochen Jiang <haochen.jiang@intel.com> wrote:
> > > >
> > > > Hi all,
> > > >
> > > > This RFC patch aims to add AVX10.1 options. After we added -m[no-]evex512
> > > > support, it makes a lot easier to add them comparing to the August version.
> > > > Detail for AVX10 is shown below:
> > > >
> > > > Intel Advanced Vector Extensions 10 (Intel AVX10) Architecture Specification
> > > > It describes the Intel Advanced Vector Extensions 10 Instruction Set
> > > > Architecture.
> > > > https://cdrdv2.intel.com/v1/dl/getContent/784267
> > > >
> > > > The Converged Vector ISA: Intel Advanced Vector Extensions 10 Technical Paper
> > > > It provides introductory information regarding the converged vector ISA: Intel
> > > > Advanced Vector Extensions 10.
> > > > https://cdrdv2.intel.com/v1/dl/getContent/784343
> > > >
> > > > Our proposal is to take AVX10.1-256 and AVX10.1-512 as two "virtual" ISAs in
> > > > the compiler. AVX10.1-512 will imply AVX10.1-256. They will not enable
> > > > anything at first. At the end of the option handling, we will check whether
> > > > the two bits are set. If AVX10.1-256 is set, we will set the AVX512 related
> > > > ISA bits. AVX10.1-512 will further set EVEX512 ISA bit.
> > > >
> > > > It means that AVX10 options will be separated from the existing AVX512 and the
> > > > newly added -m[no-]evex512 options. AVX10 and AVX512 options will control
> > > > (enable/disable/set vector size) the AVX512 features underneath independently.
> > > > If there’s potential overlap or conflict between AVX10 and AVX512 options,
> > > > some rules are provided to define the behavior, which will be described below.
> > > >
> > > > avx10.1 option will be provided as an alias of avx10.1-256.
> > > >
> > > > In the future, the AVX10 options will imply like this:
> > > >
> > > > AVX10.1-256 <---- AVX10.1-512
> > > > ^ ^
> > > > | |
> > > >
> > > > AVX10.2-256 <---- AVX10.2-512
> > > > ^ ^
> > > > | |
> > > >
> > > > AVX10.3-256 <---- AVX10.3-512
> > > > ^ ^
> > > > | |
> > > >
> > > > Each of them will have its own option to enable/disabled corresponding
> > > > features. The alias avx10.x will also be provided.
> > > >
> > > > As mentioned in August version RFC, since we lean towards the adoption of
> > > > AVX10 instead of AVX512 from now on, we don’t recommend users to combine the
> > > > AVX10 and legacy AVX512 options.
> > >
> > > I wonder whether adoption could be made easier by also providing a
> > > -mavx10[.0] level that removes some of the more obscure sub-ISA requirements
> > > to cover more existing implementations (I'd not add -mavx10.0-512 here).
> > > I'd require only skylake-AVX512 features here, basically all non-KNL AVX512
> > > CPUs should have a "virtual" AVX10 level that allows to use that feature set,
> > We have -mno-evex512 can cover those cases, so what you want is like a
> > simple alias of "-march=skylake-avx512 -mno-evex512"?
>
> For the AVX512 enabled sub-isas of skylake-avx512 yes I guess.
>
> > > restricted to 256bits so future AVX10-256 implementations can handle it
> > > as well as all existing (and relevant, which excludes KNL) AVX512
> > > implementations.
> > >
> > > Otherwise AVX10 is really a hard sell (as AVX512 was originally).
> > It's a rebranding of the existing AVX512 to AVX10, AVX10.0 just
> > complicated things further(considering we already have x86-64-v4 which
> > is different from skylake-avx512).
>
> Well, the cut-off for "AVX512" is quite arbitrary. Introducing a
> "new" ISA that's
> only available in HW available in the future and suggesting users to embrace
> that already (like Intel did with AVX512 without offering client SKU support)
> is a hard sell.
>
> I realize Intel thinks client SKU support for AVX10 (restricted to 256bit) will
> be "easier". But then don't expect anybody to adopt that in the next 10 years.
>
> Just to add - we were suggesting to use x86_64-v3 for the "next" enterprise
> product but got downvoted to x86_64-v2 for compatibility reasons.
>
> 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).
About the arch level is indeed a problem, especially since the default
size of avx10 is 256.
+Florian Weimer for more inputs.
>
> Richard.
>
> > >
> > > > However, we would like to introduce some
> > > > simple rules for user when it comes to combination.
> > > >
> > > > 1. Enabling AVX10 and AVX512 at the same command line with different vector
> > > > size will lead to a warning message. The behavior of the compiler will be
> > > > enabling AVX10 with longer, i.e., 512 bit vector size.
> > > >
> > > > If the vector sizes are the same (e.g. -mavx10.1-256 -mavx512f -mno-evex512,
> > > > -mavx10.1-512 -mavx512f), it will be valid with the corresponding vector size.
> > > >
> > > > 2. -mno-avx10.1 option can’t disable any features enabled by AVX512 options or
> > > > impact the vector size, and vice versa. The compiler will emit warnings if
> > > > necessary.
> > > >
> > > > For the auto dispatch support including function multi versioning, function
> > > > attribute usage, the behavior will be identical to compiler options.
> > > >
> > > > If you have any questions, feel free to ask in this thread.
> > > >
> > > > Thx,
> > > > Haochen
> > > >
> > > >
> >
> >
> >
> > --
> > BR,
> > Hongtao
--
BR,
Hongtao
next prev parent reply other threads:[~2023-11-14 2:40 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 [this message]
2023-11-14 6:25 ` Jiang, Haochen
2023-12-12 9:05 ` Florian Weimer
2023-12-12 12:14 ` Richard Biener
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='CAMZc-bykR4NoXwojHozaOGY4W5LSDiNABui7rd4Dv0GhT5=zSg@mail.gmail.com' \
--to=crazylht@gmail.com \
--cc=fweimer@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=haochen.jiang@intel.com \
--cc=hongtao.liu@intel.com \
--cc=richard.guenther@gmail.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).