[PATCH] Add AMD znver6 processor support

[Jiang, Haochen]

> From: Gopalasubramanian, Ganesh <Ganesh.Gopalasubramanian@amd.com>
> Sent: Monday, November 17, 2025 1:44 PM
> 
> -----Original Message-----
> From: Jiang, Haochen <haochen.jiang@intel.com>
> Sent: Monday, November 17, 2025 9:03 AM
> 
> 
> > 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.
> 

Typically under AVX512F related insts, it should be:

Only enable AVX512BMM -> zmm version available
Further enable AVX512VL -> xmm/ymm version available

Thus, AVX512VL is an option or a switch to turn on xmm/ymm, not a must.

> 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?"
> 

I suppose the question is a different scenario with AVX512VL issues. It is
a question whether we should imply AVX512BW.

I would prefer the latter one. The previous one will lead to splitting the
CPUID into insts, which is too detailed and not needed for that
small scope. Since we need those mmask64 usage,  we need to imply
AVX512BW.

Thx,
Haochen