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

[Peter Maydell]

On Fri, 13 Aug 2021 at 17:59, Richard Henderson
<richard.henderson@linaro.org> 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.
>
> > More generally, is there somewhere we can assert that we
> > didn't try to use a REXW prefix for i386 codegen rather
> > than just silently ignoring it ?
>
> I guess tcg_out_opc might be a place.  But mostly we try to avoid generating 
> those places
> in the first place.  E.g.
>
> #if TCG_TARGET_REG_BITS == 64
> # define OP_32_64(x) \
>          case glue(glue(INDEX_op_, x), _i64): \
>              rexw = P_REXW; /* FALLTHRU */    \
>          case glue(glue(INDEX_op_, x), _i32)
> #else
> # define OP_32_64(x) \
>          case glue(glue(INDEX_op_, x), _i32)
> #endif

Right, if we do that everywhere we could make P_REXW the same value
on 32 bit and 64 bit hosts and assert that P_REXW doesn't ever actually
get passed to the functions where we look at it to generate
code. It's only if there's codepaths which rely on P_REXW being 0
on i386 in order to not generate invalid code that an assert would
get awkward...

-- PMM