[PATCH 0/3] Refine AVX10.2 mnemonics

[Christian Ludloff]

> > >> > One more: don't forget the 256-bit {er} variants of VCVTDQ2PD at
> > >> > F3.0F__.W0.E6 and VCVTUDQ2PD at F3.0F__.W0.7A – they are missing
> > >> > from the AVX10.2 spec; they should be supported, similar to the
> > >> > existing 512-bit {er} variants: attempts to encode {er} should be
> > >> > ignored, as documented in the SDM.
> >
> > > Hopefully all the AVX10.2 silicon got it right in the first place.
> >
> > Fwiw, the latest AVX10.2 spec (#361050-003 from Jan 14) is still missing the
> > 256-bit {er} variants of VCVT[,U]DQ2PD.
> >
> > For now, we have the unofficial confirmation here:
> >
> >   https://sourceware.org/pipermail/binutils/2025-January/138698.html
>
> I suppose it is not included due to it actually has no rounding operand
> normally. We just ignore that rounding if someone got the bytecode with
> rounding. So when doc is there, it won't be included. Maybe we could get
> a better way to get that. (Actually when AVX10.2 things went into SDM,
> everything would be aligned.) Let me try to find a way.

The AVX10.2 spec went to great length to list all those existing
instructions for which their LL=256 variant now permits U=0 – it
included CVT[,U]DQ2{PH,PS} but not CVT[,U]DQ2PD.

Perhaps clone table entries for PD from table entries for PH/PS,
and likewise clone instruction pages for PD from PH/PS but add
the SDM statement "Attempt to encode this instruction with EVEX
embedded rounding is ignored." on the PD pages.

For SDM, it is probably best to add {er} to the four affected CVTs,
perhaps as {er.ignored}. That way their "Attempt to..." statements
would no longer be dangling as much.

Fwiw, I have seen various tools emit the {er} for LL=512, as they
handle PH/PS/PD identically, rather than special-case PD. And I
expect to see this carry over to LL=256. Which is why I think it is
important that the spec and the chips get it right (no #UD).

Thanks for your hard work!

--
C.