Re: [PATCH for-6.1] tcg/i386: Split P_VEXW from P_REXW

[Richard Henderson]

On 8/13/21 6:59 AM, Richard Henderson wrote:
> On 8/13/21 12:37 AM, Peter Maydell wrote:
> > These changes look OK as far as they go, but it's not clear to
> > me why the other places that set P_REXW are all OK to use P_REXW
> > and not P_VEXW. For instance tcg_out_mov() sets rexw = P_REXW
> > and some of the codepaths there will then pass that into
> > tcg_out_vex_modrm() which ends up in tcg_out_vex_opc().
>
> This distinguishes between 32-bit and 64-bit transfer between vector and general register. 
>   Which of course doesn't make sense for i386.

I read this again and realized it doesn't really clear things up.

The older opcodes which originated with SSE used completely separate opcodes to talk about 
64-bit quantities within the vector registers.  E.g.

#define OPC_PSLLW       (0xf1 | P_EXT | P_DATA16)
#define OPC_PSLLD       (0xf2 | P_EXT | P_DATA16)
#define OPC_PSLLQ       (0xf3 | P_EXT | P_DATA16)

or even

#define OPC_MOVQ_VqWq   (0x7e | P_EXT | P_SIMDF3)
#define OPC_MOVQ_WqVq   (0xd6 | P_EXT | P_DATA16)

It's only with the newest AVX2 instructions that they decided to use VEX.W to talk about 
the size of the vector element as opposed to the size of the general register on the other 
end.  Which includes the two vector shift with the shift amount coming from a vector 
argument (as opposed to immediate):

#define OPC_VPSLLVD     (0x47 | P_EXT38 | P_DATA16)
#define OPC_VPSLLVQ     (0x47 | P_EXT38 | P_DATA16 | P_VEXW)
#define OPC_VPSRLVD     (0x45 | P_EXT38 | P_DATA16)
#define OPC_VPSRLVQ     (0x45 | P_EXT38 | P_DATA16 | P_VEXW)

I guess I can add
Fixes: a2ce146a068 ("tcg/i386: Support vector variable shift opcodes")

because I failed to consider that P_REXW was always 0 for 32-bit.


r~