[PATCH 3/5] x86: support AVX10.1/512

[Jan Beulich]

On 28.08.2023 04:34, Jiang, Haochen wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Friday, August 25, 2023 8:47 PM
>> To: Binutils <binutils@sourceware.org>
>> Cc: H.J. Lu <hjl.tools@gmail.com>; Jiang, Haochen <haochen.jiang@intel.com>
>> Subject: [PATCH 3/5] x86: support AVX10.1/512
>> --- a/opcodes/i386-opc.tbl
>> +++ b/opcodes/i386-opc.tbl
>> @@ -1762,22 +1762,28 @@ vpgatherq<dq>, 0x6691, AVX2, Modrm|Vex12
>>  vpgatherqd, 0x6691, AVX2,
>> Modrm|Vex256|Space0F38|VexVVVV|VexW0|SwapSources|NoSuf|VecSIB256,
>> { RegXMM, Dword|Unspecified|BaseIndex, RegXMM }
>>  vpgatherqq, 0x6691, AVX2,
>> Modrm|Vex256|Space0F38|VexVVVV|VexW1|SwapSources|NoSuf|VecSIB256,
>> { RegYMM, Qword|Unspecified|BaseIndex, RegYMM }
>>
>> +// AVX10 is somewhat special wrt VAES and VPCLMULQDQ: The latter two imply
>> +// 256-bit VEX encodings, but surely the 128-bit forms are also supported.
>> +// Short of making AES a prereq of VAES (and PCLMULQDQ for VPCLMULQDQ) in
>> +// i386-gen, add otherwise redundant secondary templates here.
>> +<avx10:cpu, $avx:AVX|, $avx10:AVX512F|V>
>> +
> 
> Should it be AVX512VL instead of AVX512F here? I am not sure if elsewhere in as will
> help check AVX512VL for EVEX encoding xmm register usage.

Oh, yes, I think you're right. These aren't templates allowing for multiple
operand sizes. Thanks for spotting.

But of course the question remains on whether this is needed in the first
place. Personally I'd favor making AES a prereq of VAES (and PCLMULQDQ one
of VPCLMULQDQ); if we decided to go that route, I'd make that change a
separate prereq patch. Yet before that a clarification in the AVX10 spec
(or even in the SDM itself) would of course be quite helpful, albeit of
course we have some leeway here, as there's some level of discretion that
we have as to what exact effects -march= / .arch have.

Jan