[PATCH v5] Add AMD znver6 processor support

[Jiang, Haochen]

> From: Jan Beulich <jbeulich@suse.com>
> Sent: Tuesday, November 25, 2025 8:55 PM
> 
> On 24.11.2025 16:35, Umesh Kalvakuntla wrote:
> >> Assuming this will (eventually) need applying on your behalf,
> > Yes.
> >
> >> can we  get a git-am-able form of the patch, though? The above has extra
> >> indentation, which I'm not sure "git am" would properly strip.
> > Generated now with git format-patch.
> >
> >> You will want to alter operands such that the ModR/M byte ends up as a
> >> single-byte opcode, such that the disassembler will properly recognize
> >> the insn boundary ahead of the 2nd insn under test.
> > Added .fill directive following other examples. Now both are
> > disassembled as invalid.
> 
> But why? .fill adds volume and noise, and hence it or alike should be used
> only as a last resort. I did explain what you want to do to avoid the need
> for .fill.
> 
> You didn't address the CpuUnused aspect though. That's fine given the plan
> we look to have agreed on, but such an aspect still needs pointing out.
> For example, to make sure someone other than Haochen or me ending up
> committing this patch (once a final okay way given) wouldn't break things
> unknowingly.
> 
> > --- a/gas/doc/c-i386.texi
> > +++ b/gas/doc/c-i386.texi
> > @@ -126,6 +126,7 @@ processor names are recognized:
> >  @code{znver3},
> >  @code{znver4},
> >  @code{znver5},
> > +@code{znver6},
> 
> Noticing only now: Unlike this one, ...
> 
> >  @code{btver1},
> >  @code{btver2},
> >  @code{generic32} and
> > @@ -198,6 +199,7 @@ accept various extension mnemonics.  For example,
> >  @code{avx512_bf16},
> >  @code{avx_vnni},
> >  @code{avx512_fp16},
> > +@code{avx512_bmm},
> 
> ... this doesn't have a counterpart ...
> 
> > @@ -1691,9 +1693,9 @@ supported on the CPU specified.  The choices for
> @var{cpu_type} are:
> >  @item @samp{k6} @tab @samp{k6_2} @tab @samp{athlon} @tab
> @samp{k8}
> >  @item @samp{amdfam10} @tab @samp{bdver1} @tab @samp{bdver2}
> @tab @samp{bdver3}
> >  @item @samp{bdver4} @tab @samp{znver1} @tab @samp{znver2} @tab
> @samp{znver3}
> > -@item @samp{znver4} @tab @samp{znver5} @tab @samp{btver1} @tab
> @samp{btver2}
> > -@item @samp{generic32}
> > -@item @samp{generic64} @tab @samp{.cmov} @tab @samp{.fxsr} @tab
> @samp{.mmx}
> > +@item @samp{znver4} @tab @samp{znver5} @tab @samp{znver6} @tab
> @samp{btver1}
> > +@item @samp{btver2} @tab @samp{generic32} @tab @samp{generic64}
> > +@item @samp{.cmov} @tab @samp{.fxsr} @tab @samp{.mmx}
> 
> ... down below here.
> 

I don't know why the v6 patch never bump into my mailbox, neither the initial
v5 patch. All I got is this mail, so I have to reply this thread.

For the table change, I just realized you end up with splitting them into different
entries. Derived from your patch:

> > +// AVX512_BMM instructions.
> > +
> > +vbmacor16x16x16, 0x80, AVX512_BMM&AVX512VL, Modrm|EVex256|VexW0|Src1VVVV|Map6|Disp8ShiftVL|CheckOperandSize|NoSuf, { RegYMM|Unspecified|BaseIndex, RegYMM, RegYMM }
> > +vbmacor16x16x16, 0x80, AVX512_BMM, Modrm|EVex512|VexW0|Src1VVVV|Map6|Disp8ShiftVL|CheckOperandSize|NoSuf, { RegZMM|Unspecified|BaseIndex, RegZMM, RegZMM }
> > +vbmacxor16x16x16, 0x80, AVX512_BMM&AVX512VL, Modrm|EVex256|VexW1|Src1VVVV|Map6|Disp8ShiftVL|CheckOperandSize|NoSuf, { RegYMM|Unspecified|BaseIndex, RegYMM, RegYMM }
> > +vbmacxor16x16x16, 0x80, AVX512_BMM, Modrm|EVex512|VexW1|Src1VVVV|Map6|Disp8ShiftVL|CheckOperandSize|NoSuf, { RegZMM|Unspecified|BaseIndex, RegZMM, RegZMM }
> > +vbitrevb, 0x81, AVX512_BMM&AVX512VL, Modrm|EVexDYN|VexW0|Masking|Map6|Disp8ShiftVL|CheckOperandSize|NoSuf, { RegXMM|RegYMM|Unspecified|BaseIndex, RegXMM|RegYMM }
> > +vbitrevb, 0x81, AVX512_BMM, Modrm|EVex512|VexW0|Masking|Map6|Disp8ShiftVL|CheckOperandSize|NoSuf, { RegZMM|Unspecified|BaseIndex, RegZMM }

I believe it could be simply combined to the entry just like how your initial
patch looked like with Disp8ShiftVL and CheckOperandSize added into them.

Why did you split them out eventually? Did I miss something you mentioned
the reason for that?

If you decide to split them eventually (I believe no need to split), then

  - For all the zmm entries and vbmacor16x16x16 ymm entry,
    CheckOperandSize is not needed. Also you should directly specify
    Disp8MemShift to those four entries, for zmm should be 6 and ymm
    should be 5 since we do not need to drop into Disp8ShiftVL logic.
  - Specify the reason why you have to do that in the patch description.

Thx,
Haochen