On Tue, Aug 22, 2023 at 5:20 AM Jiang, Haochen <haochen.ji...@intel.com> wrote: > > > -----Original Message----- > > From: ZiNgA BuRgA <zingabu...@hotmail.com> > > Sent: Monday, August 21, 2023 5:27 PM > > To: Richard Biener <richard.guent...@gmail.com>; Hongtao Liu > > <crazy...@gmail.com> > > Cc: Jiang, Haochen <haochen.ji...@intel.com>; gcc-patches@gcc.gnu.org > > Subject: Re: Intel AVX10.1 Compiler Design and Support > > > > 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 > > I am considering a proposal quite similar to this if we want to change the > design so that it is flexible. > > But there are a few proposals on the table. The problem for this proposal > is that if it is a over-design to make each AVX512 feature to split since in > most > scenarios we just need to keep the vector width as the same.
I think internally we should have conditional 512bit support work across AVX512 and AVX10. I also think it makes sense to _internally_ have AVX10.1 (10.1!) just enable the respective AVX512 features. AVX10.2 would then internally cover the ISA extensions added in 10.2 only. Both would reduce the redundancy and possibly make providing inter-operation between AVX10.1 (10.1!) and AVX512 to the user easier. I see AVX 10.1 (10.1!) just as "re-branding" latest AVX512, so we should treat it that way (making it an alias to the AVX512 features). Whether we want allow -mavx10.1 -mno-avx512cd or whether we only allow the "positive" -mavx512f -mavx512... (omitting avx512cd) is an entirely separate question. But I think to not wreck the core idea (more interoperability, here between small/big cores) we absolutely have to provide a subset of avx10.1 but with disabled 512bit vectors which effectively means AVX512 with disabled 512bit support. Richard. > > Thx, > Haochen > > > > > > > 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. > > >
