Another way (not saying this is better, just throwing out ideas) is to
break AVX10.1 into all the AVX-512 subsets.
So you'd have something like -mavx10.1-256-vl, -mavx10.1-512-vbmi etc.
* -mavx10.1-256 would effectively be an alias for all the 128+256-bit
subsets, and set the __AVX10_1__ define
* -mavx512vbmi would effectively be an alias for `-mavx10.1-128-vbmi
-mavx10.1-256-vbmi -mavx10.1-512-vbmi` and set the __AVX512VBMI__ define
(`-mavx10.1-512-vl` might not make much sense unless it implies AVX512F?)
* -mno-avx512vbmi would similarly be an alias for
`-mno-avx10.1-128-vbmi -mno-avx10.1-256-vbmi -mno-avx10.1-512-vbmi`;
with this, `-mavx10.1-256 -mno-avx512vbmi` would make sense, even if
unusual (enable all AVX10.1 but disable all VBMI)
* -mavx10.2-256 would act as a single feature, cementing in AVX10.2
like the current AVX10.1 proposal, and AVX-512 subsets can't be turned off
On 21/08/2023 5:36 pm, Richard Biener wrote:
On Mon, Aug 21, 2023 at 3:20 AM Hongtao Liu via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
Yes. Note we cannot really re-purpose -mprefer-vector-width=256 since that
would also make uses of 512bit intrinsics ill-formed. So we'd need a new
flag that would restrict AVX512VL to 256bit, possibly using a common internal
flag for this and the -mavx10.1-256 vector size effect.
Maybe -mdisable-vector-width-512 or -mavx512vl-for-avx10.1-256 or
-mavx512vl-256? Writing these the last looks most sensible to me?
Note it should combine with -mavx512vl to -mavx512vl-256 to make
-march=native -mavx512vl-256 work (I think we should also allow the
flag together with -mavx10.1*?)
mavx512vl-256
Target ...
Disable the 512bit vector ISA subset of AVX512 or AVX10, enable
the 256bit vector ISA subset of AVX512.
Richard.
