> -----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
