On Fri, 13 Aug 2021 at 17:59, Richard Henderson <richard.hender...@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
