[PATCH] Add AMD znver6 processor support

[Gopalasubramanian, Ganesh]

-----Original Message-----
From: Jiang, Haochen <haochen.jiang@intel.com> 
Sent: Monday, November 17, 2025 9:03 AM


> diff --git a/gas/testsuite/gas/i386/x86-64-arch-6.s
> b/gas/testsuite/gas/i386/x86-64-arch-6.s
> new file mode 100644
> index 00000000000..58d80b5bc88
> --- /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.

> +  /* 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?"

> Another question is, will there be official documentation available in the near future? For Binutils, encoding info provided in patch is probably ok if you are with strong confidence nothing would change. But for GCC, which needs runtime test, the info is not enough for only those provided.
Pseudocode are needed.

Yes. The document would be made available however we don't have the exact dates. We wanted to early enable binutils so documented the required info for binutils here.

The BMACOR operation does the BMM with OR reduction in each 256-bit lane, and then does a bitwise OR with the accumulate input across the whole result

Regards
Ganesh