On Mon, Jan 27, 2025 at 3:54 PM Jiang, Haochen <haochen.ji...@intel.com> wrote:
>
> > 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.
IMO -mavx10.2-512 -mno-avx10.2-512 should cancel, thus not leave -mavx10.2-256
on. Mixing both ISA and width into a single set of options makes
combinations quite
awkward - consider
-mavx10.2-256 -mavx10.2-512 -mno-avx10.2-512 -- should leave all of
avx10.2 disabled?
-mavx10.2-512 -mavx10.2-256 -- gets you 512? or 256?
-mavx10.2-256 -mno-avx10.2-512 -mavx10.2-512 -- gets you 512
so you have to disable AVX 10.x with either -mno-avx10.2-256 or -mno-avx10.2-512
to switch from -512 to -256 or vice versa. That means people would
need to remember
to always apppend -mno-avx10.x-256 -mavx10.x-WIDTH when they want to override
previous settings with something specific.
If I'd were to re-design this from scratch I'd have
-mavx10.2-{256,512} but no negative form
-m[no-]avx10.2
with -mavx10.2 controlling the ISA and -mavx10.2-{256,512} controlling
the width.
-mavx10.2-{256,512} might imply -mavx10.2 and -mavx10.2 would imply a default
width.
For -mavx10.2-{256,512} the latest option would take precedence (so it'd be
-mavx10.2={256,512} and not really two independent options).
> -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.
So I like Option c), drop -m[no-]avx10.1 from GCC 15 (and not
introduce -m[no-]avx10.2).
But then as said above mixing two concepts will result in confusion.
An important
part will be to ensure all the different option combinations end up
behaving the same
between different compilers.
Iff we settle on something incompatible with GCC 14 (that is, you get
semantically
different behavior), then I'd recommend to backport the change to GCC
14 as well,
even if we usually would try to avoid that.
Richard.
> 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
