Re: [PATCH V2 2/4] x86/insn: Add AVX-512 support to the instruction decoder

[Adrian Hunter <adrian.hunter@intel.com>]

On 01/12/2025 21:01, Borislav Petkov wrote:
> On Mon, Dec 01, 2025 at 08:15:19PM +0200, Adrian Hunter wrote:
>> EXTRQ Vo,Uo (66) has a mandatory 66 prefix like vcvtps2uqq/pd2uqq Vx,Wx (66),(ev) so they end up on the same attribute table, but (ev) results in INAT_EVEXONLY which is unwanted.
>>
>> Changing that from (ev) to (evo) is probably all that is needed e.g.
>>
>> +79: VMWRITE Gy,Ey | EXTRQ Vo,Uo (66) | vcvtps2udq/pd2udq Vx,Wpd (evo) | vcvtsd2usi Gv,Wx (F2),(ev) | vcvtss2usi Gv,Wx (F3),(ev) | vcvtps2uqq/pd2uqq Vx,Wx (66),(evo)
>>
> 
> That still sounds to me like a hack: looking at the SDM, that thing:
> 
> VCVTPS2UQQ—Convert Packed Single Precision Floating-Point Values to Packed
> Unsigned Quadword Integer Values
> 
> *is* EVEX-only insn:
> 
> EVEX.128.66.0F.W0

The instruction decoder is permissive in the sense that it cannot
tell if an instruction is valid, only what its properties are assuming
it is valid.  There is no need to validate EVEX-only.

ev->evo makes sense to allow for another instruction.

> 
> the "66" meaning in this case EVEX.pp which are the VEX.pp two bits with value
> 1b meaning there's an implied 66 legacy prefix.
> 
> To make it more concrete, let's take an example from the binutils testsuite:
> 
> 62 f1 7d 4f 79 f5[    ]*vcvtps2uqq zmm6\{k7\},ymm5
> 
> and that's basically:
> 
> Extended VEctor prefiX:         0x62
>   P1: [R:1|X:1|B:1|R':1|rsv:0|mm:1] 0xf1
>   P2: [W:0|vvvv:0xf    |rsv:1|pp:1] 0x7d
>   P3: [z:0|L':1|L:0|b:0|V':1|aaa:7] 0x4f
> 
> with the opcode 0x79 and EVEX.pp=1b, as expected.
> 
> So there's no real 66 prefix there.
> 
> But our opcode map says:
> 
> "# Last Prefix Superscripts
> #  - (66): the last prefix is 0x66"
> 
> So we're using the marking (66) to mean both an explicit 66 legacy prefix and
> an implied *VEX.pp=1 66 prefix equivalence.
> 
> So now the question is, why do the *VEX opcodes need that (66) marking at all?
> For operand sizing?
> 
> Looking at our example insn VCVTPS2UQQ, I don't see any other encoding where
> 66 is not present. And there's nothing in the pseudo code either. So VEX.pp=1
> is part of the encoding of that insn.
> 
> So, that (66) there is not really the prefix ...

It puts the instruction into a different opcode/addressing-mode space
(different attribute table) so we probably need to keep using it like that.