From: Hongtao Liu <crazylht@gmail.com>
To: ZiNgA BuRgA <zingaburga@hotmail.com>
Cc: "Hu, Lin1" <lin1.hu@intel.com>,
"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH 00/18] Support -mevex512 for AVX512
Date: Sat, 7 Oct 2023 10:33:13 +0800 [thread overview]
Message-ID: <CAMZc-bwzUAGcd3f=-etvLbMVF2dhrYBU2np9VX+p_FzGLvp3Kw@mail.gmail.com> (raw)
In-Reply-To: <OS3P286MB0584EB9C03FE1059830F4185D7C1A@OS3P286MB0584.JPNP286.PROD.OUTLOOK.COM>
On Thu, Sep 28, 2023 at 11:23 AM ZiNgA BuRgA <zingaburga@hotmail.com> wrote:
>
> That sounds about right. The code I had in mind would perhaps look like:
>
>
> #if defined(__AVX512BW__) && defined(__AVX512VL__)
> #if defined(__EVEX256__) && !defined(__EVEX512__)
> // compiled code is AVX10.1/256 and AVX512 compatible
> #else
> // compiled code is only AVX512 compatible
> #endif
>
> // some code which only uses 256b instructions
> __m256i...
> #endif
>
>
> The '__EVEX256__' define would avoid needing to check compiler versions.
Sounds reasonable, regarding how to set __EVEX256__, I think it should
be set/unset along with __AVX512VL__ and __EVEX512__ should not unset
__EVEX256__.
> Hopefully you can align it with whatever Clang does:
> https://discourse.llvm.org/t/rfc-design-for-avx10-feature-support/72661/18
>
> Thanks!
>
> On 28/09/2023 12:26 pm, Hu, Lin1 wrote:
> > Hi,
> >
> > Thanks for you reply.
> >
> > I'd like to verify that our understanding of your requirements is correct, and that __EVEX256__ can be considered a default macro to determine whether the compiler supports the __EVEX***__ series of switches.
> >
> > For example:
> >
> > I have a segment of code like:
> > #if defined(__EVEX512__):
> > __mm512.*__;
> > #else
> > __mm256.*__;
> > #endif
> >
> > But __EVEX512__ is undefined that doesn't mean I only need 256bit, maybe I use gcc-13, so I can still use 512bit.
> >
> > So the code should be:
> > #if defined(__EVEX512__):
> > __mm512.*__;
> > #elif defined(__EVEX256__):
> > __mm256.*__;
> > #else
> > __mm512.*__;
> > #endif
> >
> > If we understand correctly, we'll consider the request. But since we're about to have a vacation, follow-up replies may be a bit slower.
> >
> > BRs,
> > Lin
> >
> > -----Original Message-----
> > From: ZiNgA BuRgA <zingaburga@hotmail.com>
> > Sent: Thursday, September 28, 2023 8:32 AM
> > To: Hu, Lin1 <lin1.hu@intel.com>; gcc-patches@gcc.gnu.org
> > Subject: Re: [PATCH 00/18] Support -mevex512 for AVX512
> >
> > Thanks for the new patch!
> >
> > I see that there's a new __EVEX512__ define. Will there be some __EVEX256__ (or maybe some max EVEX width) define, so that code can detect whether the compiler supports AVX10.1/256 without resorting to version checks?
> >
> >
>
--
BR,
Hongtao
prev parent reply other threads:[~2023-10-07 2:33 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-21 7:19 Hu, Lin1
2023-09-21 7:19 ` [PATCH 01/18] Initial support for -mevex512 Hu, Lin1
2023-10-07 6:34 ` [PATCH v2 " Haochen Jiang
2023-09-21 7:19 ` [PATCH 02/18] [PATCH 1/5] Push evex512 target for 512 bit intrins Hu, Lin1
2023-09-21 7:19 ` [PATCH 03/18] [PATCH 2/5] " Hu, Lin1
2023-09-21 7:19 ` [PATCH 04/18] [PATCH 3/5] " Hu, Lin1
2023-09-21 7:20 ` [PATCH 05/18] [PATCH 4/5] " Hu, Lin1
2023-09-21 7:20 ` [PATCH 06/18] [PATCH 5/5] " Hu, Lin1
2023-09-21 7:20 ` [PATCH 07/18] [PATCH 1/5] Add OPTION_MASK_ISA2_EVEX512 for 512 bit builtins Hu, Lin1
2023-09-21 7:20 ` [PATCH 08/18] [PATCH 2/5] " Hu, Lin1
2023-09-21 7:20 ` [PATCH 09/18] [PATCH 3/5] " Hu, Lin1
2023-09-21 7:20 ` [PATCH 10/18] [PATCH 4/5] " Hu, Lin1
2023-09-21 7:20 ` [PATCH 11/18] [PATCH 5/5] " Hu, Lin1
2023-09-21 7:20 ` [PATCH 12/18] Disable zmm register and 512 bit libmvec call when !TARGET_EVEX512 Hu, Lin1
2023-09-21 7:20 ` [PATCH 13/18] Support -mevex512 for AVX512F intrins Hu, Lin1
2023-09-21 7:20 ` [PATCH 14/18] Support -mevex512 for AVX512DQ intrins Hu, Lin1
2023-09-21 7:20 ` [PATCH 15/18] Support -mevex512 for AVX512BW intrins Hu, Lin1
2023-09-21 7:20 ` [PATCH 16/18] Support -mevex512 for AVX512{IFMA,VBMI,VNNI,BF16,VPOPCNTDQ,VBMI2,BITALG,VP2INTERSECT},VAES,GFNI,VPCLMULQDQ intrins Hu, Lin1
2023-09-21 7:20 ` [PATCH 17/18] Support -mevex512 for AVX512FP16 intrins Hu, Lin1
2023-09-21 7:20 ` [PATCH 18/18] Allow -mno-evex512 usage Hu, Lin1
2023-09-22 3:30 ` [PATCH 00/18] Support -mevex512 for AVX512 Hongtao Liu
2023-09-28 0:32 ` ZiNgA BuRgA
2023-09-28 2:26 ` Hu, Lin1
2023-09-28 3:23 ` ZiNgA BuRgA
2023-10-07 2:33 ` Hongtao Liu [this message]
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-bwzUAGcd3f=-etvLbMVF2dhrYBU2np9VX+p_FzGLvp3Kw@mail.gmail.com' \
--to=crazylht@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=lin1.hu@intel.com \
--cc=zingaburga@hotmail.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).