public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
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

      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).