Re: [PATCH 6/8] Support APX Push2/Pop2

[Jan Beulich <jbeulich@suse.com>]

On 02.11.2023 12:29, Cui, Lili wrote:
> --- a/opcodes/i386-opc.tbl
> +++ b/opcodes/i386-opc.tbl
> @@ -3494,3 +3494,10 @@ erets, 0xf20f01ca, FRED|x64, NoSuf, {}
>  eretu, 0xf30f01ca, FRED|x64, NoSuf, {}
>  
>  // FRED instructions end.
> +
> +// APX Push2/Pop2 instruction.
> +
> +push2, 0xff/6, APX_F, Modrm|VexW0|EVex128|Push2Pop2|EVexMap4|VexVVVVSrc|No_bSuf|No_wSuf|No_lSuf|No_sSuf, { Reg64, Reg64 }
> +push2p, 0xff/6, APX_F, Modrm|VexW1|EVex128|Push2Pop2|EVexMap4|VexVVVVSrc|No_bSuf|No_wSuf|No_lSuf|No_sSuf, { Reg64, Reg64 }
> +pop2, 0x8f/0, APX_F, Modrm|VexW0|EVex128|Push2Pop2|EVexMap4|VexVVVVSrc|No_bSuf|No_wSuf|No_lSuf|No_sSuf, { Reg64, Reg64 }
> +pop2p, 0x8f/0, APX_F, Modrm|VexW1|EVex128|Push2Pop2|EVexMap4|VexVVVVSrc|No_bSuf|No_wSuf|No_lSuf|No_sSuf, { Reg64, Reg64 }

I think the use of the VexVVVV attribute here wants to be consistent with
that in the earlier patch used for e.g. NEG: Nominally (i.e. notation-wise)
the last operand is the destination operand in both cases (even if in
practice it's a source one here). The resulting encoding being the same is
merely an effect resulting from ModR/M.reg being used for an opcode
extension in both cases (which takes priority over register assignment in
build_modrm_byte()). But: I came to spot the inconsistency when looking at
patch 7, which keys off of VexVVVVDst. Obviously when making things
consistent here, there would then need to be measures to avoid the
optimization kicking in on the insns here. Hence an alternative to using
VexVVVVDst here would be a clarifying / justifying comment.

Jan