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 <pbonzini@redhat.com>
---
 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