[PATCH] Add AMD znver6 processor support

[Jan Beulich]

On 17.11.2025 06:43, Gopalasubramanian, Ganesh wrote:
> -----Original Message-----
> From: Jiang, Haochen <haochen.jiang@intel.com> 
> Sent: Monday, November 17, 2025 9:03 AM
> 
>> --- /dev/null
>> +++ b/gas/testsuite/gas/i386/x86-64-arch-6.s
>> @@ -0,0 +1,8 @@
>> +# Test -march=
>> +     .text
>> +
>> +     vbmacor16x16x16 %ymm1, %ymm2, %ymm3     #AVX512BMM
>> +     vbcstnebf162ps (%edx), %xmm1            #AVX_NE_CONVERT
>> +        vpmadd52huq %xmm1, %xmm1, %xmm2              #AVX_IFMA
>> +     vpdpbssd %ymm1, %ymm2, %ymm3            #AVX_VNNI_INT8
>> +     vaddph %zmm1, %zmm2, %zmm3              #AVX512-FP16
> 
>> As Jan said in the previous review, I also doubt the test would pass even w/o
>> -march=znver6 since unlike GCC, Binutils is ISA default on mode.
> 
> Yes. binuils by default supports all ISAs. However, we would like to have -march support to have the support notified for assembler and disassembler users.
> The name is used as an indicator that zen6 subtarget is enabled in binutils and for --help. We prefer to retain this.

The please add a justifying sentence to the patch description.

>> +  /* EVEX_W_MAP6_81 */
>> +  {
>> +    { "vbitrev", { XM, EXx }, NO_PREFIX },
>> +    { Bad_Opcode }
>> +  }
>> diff --git a/opcodes/i386-gen.c b/opcodes/i386-gen.c index 
>> bc86f2befbb..dbea02f1a9f 100644
>> --- a/opcodes/i386-gen.c
>> +++ b/opcodes/i386-gen.c
>> @@ -208,6 +210,8 @@ static const dependency isa_dependencies[] =
>>      "AVX512BW" },
>>    { "AVX512_VP2INTERSECT",
>>      "AVX512F" },
>> +  { "AVX512_BMM",
>> +    "AVX512VL|AVX512BW" },
> 
>> My comment misleads you. Jan is right, we do not need AVX512VL here.
>> VL would be checked when using EVEX xmm/ymms. Since there are also zmm insts that do not need VL at all, implying VL here is wrong.
> 
> I am not sure if we need to remove AVX512VL. 
> AVX512VL enables AVX-512 instructions to operate on 128-bit and 256-bit registers, while AVX512BW adds support for instructions that operate on smaller data types like bytes and words.
> For BMM, if we take BITREV as an example, 
>     EVEX.128.NP.MAP6.W0 81 /r VBITREV  xmm1{k1}{z}, xmm2/m128
>     EVEX.256.NP.MAP6.W0 81 /r VBITREV  ymm1{k1}{z}, ymm2/m256
>     EVEX.512.NP.MAP6.W0 81 /r VBITREV  zmm1{k1}{z}, zmm2/m512
> 
> We need EVEX.128 and EVEX.256 to be checked which is a VL extension. Also, we operate on smaller data type (byte for BITREV) So ,should we remove it? 
> As we know, the AVX512VL flag alone is never sufficient to determine a given AVX-512 instruction may be encoded at vector lengths smaller than 512 bits.
> In that ways, AVX512BMM => AVX512F & AVX512BMM & AVX512VL & AVX512BW seems right. If we just do AVX512BMM => AVX512F & AVX512BMM & AVX512BW, then the BITREV with xmms and ymms are not a possibility. Am I missing any pieces here? Please help.
> 
> So, for BMM, as Ludloff pointed out, what should we prefer?
> 
> "Does FOO need a piece from prior BAR?"
>   vs
> "Does FOO imply all pieces of prior BAR?"

Just AVX512BW as a prereq is the correct (as in: consistent with the rest of the
AVX512 extensions) thing here.

Whether behavior wrt AVX512VL is consistent with everything else AVX512-ish is a
question you need to answer. If it isn't, some prereq work elsewhere may be needed.

Jan