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. > 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. Thx, Haochen > > Jakub
