> -----Original Message----- > From: Richard Biener <richard.guent...@gmail.com> > Sent: Tuesday, August 8, 2023 8:45 PM > To: Jiang, Haochen <haochen.ji...@intel.com> > Cc: Jakub Jelinek <ja...@redhat.com>; gcc-patches@gcc.gnu.org; > ubiz...@gmail.com; Liu, Hongtao <hongtao....@intel.com> > Subject: Re: Intel AVX10.1 Compiler Design and Support > > On Tue, Aug 8, 2023 at 10:15 AM Jiang, Haochen via Gcc-patches <gcc- > patc...@gcc.gnu.org> wrote: > > > > Hi Jakub, > > > > > So, what does this imply for the current ISAs? > > > > AVX10 will imply AVX2 on the ISA level. And we suppose AVX10 is an > > independent ISA feature set. Although sharing the same instructions > > and encodings, AVX10 and AVX512 are conceptual independent features, > > which means they are orthogonal. > > > > > The expectations in lots of config/i386/* is that -mavx512f / > > > TARGET_AVX512F means 512 bit vector support is available and most of > > > the various -mavx512XXX options imply -mavx512f (and -mno-avx512f > > > turns those off). And if -mavx512vl / TARGET_AVX512VL isn't > > > available, tons of places just use 512-bit EVEX instructions for > > > 256-bit or 128-bit stuff (mostly to be able to access [xy]mm16+). > > > > For AVX10, the 128/256/scalar version of the instructions are always > > there, and also for [xy]mm16+. 512 version is "optional", which needs > > user to indicate them in options. When 512 version is enabled, > > 128/256/scalar version is also enabled, which is kind of reverse relation > > between the current AVX512F/AVX512VL. > > > > Since we take AVX10 and AVX512 are orthogonal, we will add OR logic > > for the current pattern, which is shown in our AVX512DQ+VL sample patches. > > Hmm, so it sounds like AVX10 is currently, at the 10.1 level, a way to specify > AVX512F and AVX512VL "differently", so wouldn't it make sense to make it > complement those only so one can use, say, -mavx10 -mno-avx512bf16 to disable > parts of the former AVX512 ISA one doesn't like to get code generated for? > -mavx10 would then enable all the existing sub-AVX512 ISAs? >
We take AVX10 and AVX512 two independent ISAs. Therefore, it is quite weird to disable something with another unrelated ISA. I don't think -mavx10.1 -mno-avx512f should disable anything. Thx, Haochen > > > Sure, I expect all AVX10.N CPUs will have AVX512VL CPUID, will they > > > have AVX512F CPUID even when the 512-bit vectors aren't present? > > > What happens if one mixes the -mavx10* options together with > > > -mno-avx512vl or similar options? Will -mno-avx512f still imply > > > -mno-avx512vl etc.? > > > > For the CPUID part, AVX10 and AVX512 have different emulation. Only > > Xeon Server will have AVX512 related CPUIDs for backward > > compatibility. For GNR, it will be AVX512F, AVX512VL, AVX512CD, > > AVX512BW, AVX512DQ, AVX512_IFMA, AVX512_VBMI, AVX512_VNNI, > > AVX512_BF16, AVX512_BITALG, AVX512_VPOPCNTDQ, AV512_VBMI2, > > AVX512_FP16. Also, it will have AVX10 CPUIDs with 512 bit support set. Atom > Server and client will only have AVX10 CPUIDs with 256 bit support set. > > > > -mno-avx512f will still imply -mno-avx512vl. > > > > As we mentioned below, we don't recommend users to combine the AVX10 > > and legacy > > AVX512 options. We understand that there will be different opinions on > > what should compiler behave on some controversial option combinations. > > > > If there is someone mixes the options, the golden rule is that we are using > > OR logic. > > Therefore, enabling either feature will turn on the shared > > instructions, no matter the other feature is not mentioned or closed. > > That is why we are emitting warning for some scenarios, which is also > > mentioned in the letter. > > I'm refraining from commenting on the senslesness of AVX10 as you're likely on > the same receiving side as us. > > Thanks, > Richard. > > > Thx, > > Haochen > > > > > > > > Jakub > >
