x86: record further wrong uses of EVEX.b
authorJan Beulich <jbeulich@suse.com>
Fri, 14 Jan 2022 09:55:17 +0000 (10:55 +0100)
committerJan Beulich <jbeulich@suse.com>
Fri, 14 Jan 2022 09:55:17 +0000 (10:55 +0100)
For one EVEX.W set does not imply EVEX.b is uniformly valid. Reject it
for modes which occur for insns allowing for EVEX.W to be set (noticed
with VMOV{H,L}PD and VMOVDDUP, and only in AT&T mode, but not checked
whether further insns would also have been impacted; I expect e.g.
VCMPSD would have had the same issue). And then the present concept of
broadcast makes no sense at all when the memory operand of an insn is
the destination.

opcodes/i386-dis.c

index ad560b1899c1ef62a8b44f66eaf8095c5982ab60..ffb548cbe6801633e716d58f32f9e95036258360 100644 (file)
@@ -11899,6 +11899,11 @@ OP_E_memory (instr_info *ins, int bytemode, int sizeflag)
   if (ins->vex.b)
     {
       ins->evex_used |= EVEX_b_used;
+
+      /* Broadcast can only ever be valid for memory sources.  */
+      if (ins->obufp == ins->op_out[0])
+       ins->vex.no_broadcast = 1;
+
       if (!ins->vex.no_broadcast)
        {
          if (bytemode == xh_mode)
@@ -11923,6 +11928,9 @@ OP_E_memory (instr_info *ins, int bytemode, int sizeflag)
                    }
                }
            }
+         else if (bytemode == q_mode
+                  || bytemode == ymmq_mode)
+           ins->vex.no_broadcast = 1;
          else if (ins->vex.w
                   || bytemode == evex_half_bcst_xmmqdh_mode
                   || bytemode == evex_half_bcst_xmmq_mode)