The IMUL 0F AF encoding was using T0 for the (possible) memory operand so as to use a load with sign extension. However, this trick will be incompatible with APX's new data destination extension which will use "B,v" for the destination. If no VEX/EVEX prefix is present, the "B" operand type defaults to op1, hence op1 has to be "G,v" for correct decoding of the non-APX instruction.
This is only needed because EVEX map 4's 0xA0-0xAF slots reuse the decode tables for pre-APX instructions. Signed-off-by: Paolo Bonzini <[email protected]> --- target/i386/tcg/decode-new.c.inc | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/target/i386/tcg/decode-new.c.inc b/target/i386/tcg/decode-new.c.inc index 5e559d6ecb5..18b1b6845c1 100644 --- a/target/i386/tcg/decode-new.c.inc +++ b/target/i386/tcg/decode-new.c.inc @@ -1504,11 +1504,7 @@ static const X86OpEntry opcodes_0F[256] = { [0xac] = X86_OP_ENTRY4(SHRD, E,v, 2op,v, G,v), [0xad] = X86_OP_ENTRY3(SHRD, E,v, 2op,v, G,v), [0xae] = X86_OP_GROUP0(group15), - /* - * It's slightly more efficient to put Ev operand in T0 and allow gen_IMUL3 - * to assume sextT0. Multiplication is commutative anyway. - */ - [0xaf] = X86_OP_ENTRY3(IMUL3, G,v, E,v, 2op,v, sextT0), + [0xaf] = X86_OP_ENTRY2(IMUL3, G,v, E,v, sextT0), [0xb8] = X86_OP_GROUP0(0FB8), /* decoded as modrm, which is visible as a difference between page fault and #UD */ -- 2.52.0
