> From: Richard Biener <richard.guent...@gmail.com>
> Sent: Monday, January 27, 2025 5:09 PM
>
> On Mon, Jan 27, 2025 at 8:30 AM Haochen Jiang <haochen.ji...@intel.com>
> wrote:
> >
> > Hi all,
> >
> > AVX10 has been published for one and half year and we have got many
> > feedbacks on that, one of the feedback is on whether the alias option
> > -mavx10.x should point to 256 or 512.
> >
> > If you also pay attention to LLVM community, you might see this thread
> > related to AVX10 options just sent out several hours ago:
> >
> > [X86][AVX10] Disable m[no-]avx10.1 and switch m[no-]avx10.2 to alias
> > of 512 bit options
> > https://github.com/llvm/llvm-project/pull/124511
> >
> > In GCC, we will also do so. This RFC patch is slightly different with
> > LLVM, just
> > including:
> >
> > - Switch -m[no-]avx10.2 to alias of 512 bit options.
> > - Change -mno-avx10.[1,2]-512 to disable both 256 and 512 instructions.
> This
> > will also result in -mno-avx10.2 would still disable both 256 and 512
> > insts
> > according to new alias point to 512.
> >
> > But not including disabling -m[no-]avx10.1, since I still want more
> > input on how to handle that. We actually have three choices on that:
> >
> > a. Directly re-alias -m[no-]avx10.1 to -m[no-]avx10.1-512 GCC 15 and
> > backport to GCC 14.
> > b. Disable -m[no]-avx10.1 in GCC 15, and add it back with
> > -m[no-]avx10.1-512 in the future. This is for in case if someone
> > cross compile with different versions of GCC with -mavx10.1, it might get
> unexpected result sliently.
> > c. Disable -m[no]-avx10.1 in GCC 15, and never add it back. Since the
> > option has been 256 bit, changing them back and forth is messy.
> >
> > It might be the final chance we could change the alias option since
> > real
> > AVX10.1 hardware is coming soon. And it is only x86 specific, so it
> > might still squeeze into GCC 15 at this time.
> >
> > I call this patch RFC patch since we also need to change the doc and
> > testcases accordingly, which makes this patch incomplete. Discussion
> > and input is welcomed on this topic.
>
> Can you re-hash on how users need to select 256bit vs 512bit support?
> I understand
> the above change basically makes -m[no-]avx10.[12] gate ISA features but not
> size?
> So that will now enable 512bit unless -mno-evex512 is given?
>
-mno-evex512 will do nothing with AVX10 related options. It will only apply on
-mavx512xxx options.
In GCC currently, take AVX10.2 as example, we have the following options for one
AVX10 version:
-mavx10.2-256: Enable AVX10.2 ISA set with 256 bit vector size only
-mavx10.2-512: Enable AVX10.2 ISA set with both 256 and 512 bit vector size
-mavx10.2: An alias to -mavx10.2-256
Based on that, the current -mno- option would be:
-mno-avx10.2-256: Disable AVX10.2-256 ISA set, which actually disables the whole
AVX10.2.
-mno-avx10.2-512: Disable AVX10.2 ISA set 512 bit vector usage, but keep 256 bit
there.
-mno-avx10.2: An alias to -mno-avx10.2-256.
In this RFC, basically we have two main goal, both of them are introduced in
GCC 15:
- Change -mavx10.2 alias to 512 bit instead of 256 bit.
- -mno-avx10.2-512 would disable the whole AVX10.2, instead of 512 bit only,
to
eliminate different understanding on that due to in AVX10 we turned the imply
relationship from line-like to square-like. Also, it will lead to the new
-mno-avx10.2
still disable the whole AVX10.2 ISA set, which meets its first impression on
option
name.
Due to that, -mno-avx10.1-512 should also align with that, which is introduced
in
GCC 14.
> Given for the -mavx10.[12]-{256,512} the behavior changes compared to GCC
> 14 I'd rather drop the options that behave differently from GCC 14 on GCC 15
> than changing their meaning. That unfortunately will make them a hard error
> (but I don't expect much use). I'm not sure it's worth retaining -m[no-
> ]avx10.[12]-512.
-mavx10.[12]-256/512 are clear, -mno-avx10.[12]-256 is also clear. No need to
concern on that. As said, the changes are on -mavx10.x alias and
-mno-avx10.x-512, where AVX10.1 introduced in GCC 14 and AVX10.2 in GCC 15.
In my opinion, I would go either option a) or option c) for -mavx10.1. AVX10.1
options are not widely used for now due to its first appearance in GNR. So that
is why option a) could be doable although changing the meaning, but it is the
last chance for option a. Option c) is a safe choice and I pretty like it. I
don't like
option b) but I list that out since it is also a choice. I listed them all for
discussion.
For AVX10.2, since it is first introduced in GCC 15, we could change that w/o
considering compatibility issue.
>
> But maybe I'm misunderstanding the change (too many avx10.x related
> options are there).
>
Yes, that is quite confusing and takes me some time to try to illustrate them
as clear as I can.
Thx,
Haochen
