> -----Original Message----- > From: Hongtao Liu <crazy...@gmail.com> > Sent: Wednesday, August 23, 2023 10:19 AM > To: Jiang, Haochen <haochen.ji...@intel.com> > Cc: Jakub Jelinek <ja...@redhat.com>; Richard Biener > <richard.guent...@gmail.com>; ZiNgA BuRgA <zingabu...@hotmail.com>; > gcc-patches@gcc.gnu.org > Subject: Re: Intel AVX10.1 Compiler Design and Support > > On Wed, Aug 23, 2023 at 9:58 AM Jiang, Haochen > <haochen.ji...@intel.com> wrote: > > > > > -----Original Message----- > > > From: Jakub Jelinek <ja...@redhat.com> > > > Sent: Tuesday, August 22, 2023 11:02 PM > > > To: Hongtao Liu <crazy...@gmail.com> > > > Cc: Richard Biener <richard.guent...@gmail.com>; Jiang, Haochen > > > <haochen.ji...@intel.com>; ZiNgA BuRgA <zingabu...@hotmail.com>; > > > gcc- patc...@gcc.gnu.org > > > Subject: Re: Intel AVX10.1 Compiler Design and Support > > > > > > On Tue, Aug 22, 2023 at 10:35:55PM +0800, Hongtao Liu wrote: > > > > Let's assume there's no detla now, AVX10.1-512 is equal to > > > > > AVX512{F,VL,BW,DQ,CD,BF16,FP16,VBMI,VBMI2,VNNI,IFMA,BITALG,VPOPC > NT > > > > DQ} > > > > > other stuff. > > > > > The current common/config/i386/i386-common.cc > > > > > OPTION_MASK_ISA*SET* would be like now, except that the current > > > > > AVX512* sets imply also EVEX512/whatever it will be called, that > > > > > option itself enables nothing (or TARGET_AVX512F), and unsetting it > doesn't disable all the TARGET_AVX512*. > > > > > -mavx10.1 would enable the AVX512* sets without > EVEX512/whatever. > > > > So for -mavx512bw -mavx10.1-256, -mavx512bw will set EVEX512, but > > > > -mavx10.1-256 doesn't clear EVEX512 but just enable all AVX512* sets?. > > > > then the combination basically is equal to AVX10.1-512(AVX512* > > > > sets + > > > > EVEX512) > > > > If this is your assumption, yes, there's no need for TARGET_AVX10_1. > > > > I think we still need that since the current w/o AVX512VL, we will not > > only enable 512 bit vector instructions but also enable scalar > > instructions, which means when it comes to -mavx512bw -mno-evex512, > we > > should enable the scalar function. > > > > And scalar functions will also be enabled in AVX10.1-256, we need > > something to distinguish them out from the ISA set w/o AVX512VL. > Why do we need to distinguish scalar evex instruction? > As long as -mavx512XXX -mno-evex does not generate zmm/64-bit kmask, it > should be ok. > > Assume there's no delta in AVX10.1, It sounds to me the design should be like > > avx512* <== mno-evex512== avx512* + mevex512 > (no-evex512) (original AVX512 stuff) > /\ /\ > ||(equal) ||(equal) > \/ \/ > avx10.1-256 avx10.1-512 > /\ /\ > || || > || || > implied implied > || || > || || > avx10.2-256 <== implied == avx10.2-512 > /\ /\ > || || > || || > implied Implied > || || > || || > avx10.3-256 <== implied == avx10.3-512 > > 1. The new instructions in avx10.x should be put in either avx10.x-256 or > avx10.x-512 according to vector/kmask size 2. -mno-evex512 should disable - > avx10.x-512. > 3. -mavx512* will defaultly enable -mevex512, but -mavx10.1-256 will just > enable -mavx512* but not -mevex512
I will revert all the AVX10.1 patches that have been committed in trunk since the design changed if there is no objection in 24 hours. Also I am working on a sample patch for -mevex512. Although there is a little encoding issue in APX EVEX promoted KMOVQ, most of the users will not notice that. And -mavxex512 is quite straightforward. Thx, Haochen > > > > > Thx, > > Haochen > > > > > > > > I think that would be my expectation. -mavx512bw currently implies > > > 512-bit vector support of avx512f and avx512bw, and with > > > -mavx512{bw,vl} also 128-bit/256-bit vector support. All pre-AVX10 > > > chips which do support AVX512BW support 512-bit vectors. Now, > > > -mavx10.1 will bring in also > > > vl,dq,cd,bf16,fp16,vbmi,vbmi2,vnni,ifma,bitalg,vpopcntdq as you > > > wrote which weren't enabled before, but unless there is some > > > existing or planned CPU which would support 512-bit vectors in > > > avx512f and avx512bw ISAs and only support 128/256-bit vectors in > > > those dq,cd,bf16,fp16,vbmi,vbmi2,vnni,ifma,bitalg,vpopcntdq isas, I > > > think there is no need to differentiate further; the only CPUs which > > > will support both what -mavx512bw and -mavx10.1 requires will be (if > > > there is no delta) either CPUs with 128/256/512-bit vector support of > those f,vl,bw,dq,cd,...vpopcntdq ISAs, or AVX10.1-512 ISAs. > > > -mavx512vl -mavx512bw -mno-evex512 -mavx10.1-256 would on the > other > > > side disable all 512-bit vector instructions and in the end just > > > mean the same as -mavx10.1-256. > > > For just > > > -mavx512bw -mno-evex512 -mavx10.1-256 the question is if that > > > -mno-evex512 turns off also avx512bw/avx512f because avx512vl isn't > > > enabled at that point during processing, or if we do that only at > > > the end as a special case. Of course, in this exact case there is > > > no difference, because -mavx10.1-256 turns that back on. > > > But it would make a difference on > > > -mavx512bw -mno-evex512 -mavx512vl > > > (when processed right away would disable AVX512BW (because VL isn't > > > on) and in the end enable VL,F including EVEX512, or be equivalent > > > to just -mavx512bw -mavx512vl if processed at the end, because > > > -mavx512vl implied > > > -mevex512 again. > > > > > > Jakub > > > > > -- > BR, > Hongtao