> From: Richard Biener <richard.guent...@gmail.com>
> Sent: Tuesday, January 28, 2025 4:41 PM
>
> >On Mon, Jan 27, 2025 at 3:54 PM Jiang, Haochen <haochen.ji...@intel.com>
> >wrote:
> > -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.
>
> 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
It is a great idea, the negative form is quite confusing here. While I am not
quite
sure on ...
> -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).
...this. The latter taking precedence might out of some of users expectation
on how ISA option works. Typically, they would expect what they typed in
options would all be enabled. "=" might solve that but it looks a little weird
to me for an ISA option. Let's see if any others get some idea on that.
> >
> >
> > > 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.
Currently we are all on Option c).
Let me also align with LLVM guys on our opinion on how to handle that. Hope
they could also go this way so that we will have the same options.
Thx,
Haochen
