Bugzilla Link	48877
Resolution	FIXED
Resolved on	Feb 16, 2021 17:03
Version	trunk
OS	Windows NT
Blocks	#11360 #48246
CC	@topperc,@RKSimon,@phoebewang,@rotateright,@tstellar
Fixed by commit(s)	e951442 4d90477 439fd4b fa9dc0c

Extended Description

While testing the disassembler functionality using llvm-mc I found a few cases where valid encodings were incorrectly reported as errors.

It turns out that all those problematic cases were related to instructions for which the W bit from the VEX prefix is ignored.

---

Example 1.

VEX.NDS.128.66.0F38.WIG 2B /r
VPACKUSDW xmm1, xmm2, xmm3/m128

0xC4, 0xE2, 0xE9, 0x2B, 0x05, 0x15, 0x9D, 0x3F, 0x09 // NG
0xC4, 0xE2, 0x69, 0x2B, 0x05, 0x15, 0x9D, 0x3F, 0x09 // OK

The VEX.W is set in the NG case (byte #​2 is 0xE9), and cleared in the OK case (byte #​2 is 0x69).

The definition is:
defm VPACKUSDW : sse4_pack<0x2B, "vpackusdw", v8i16, v4i32, X86Packus, VR128,
i128mem, SchedWriteShuffle.XMM, load, 0>,
VEX_4V;

It is clearly missing a VEX_WIG.

---

Other problematic cases are which are affected by the same issue are:

VEX.NDS.128.66.0F38.WIG 06 /r
VPHSUBD xmm1, xmm2, xmm3/m128

0xC4, 0xE2, 0xE9, 0x06, 0x05, 0x24, 0x78, 0xF3, 0x07 // NG
0xC4, 0xE2, 0x69, 0x06, 0x05, 0x24, 0x78, 0xF3, 0x07 // OK

VEX.128.66.0F3A.WIG 61 /r ib
VPCMPESTRI xmm1, xmm2/m128, imm8

0xC4, 0xE3, 0xE9, 0x61, 0x05, 0x00, 0x25, 0x49, 0x02, 0x60 // OK
0xC4, 0xE3, 0xF9, 0x61, 0x05, 0x00, 0x25, 0x49, 0x02, 0x60 // NG

VPCMPESTRM xmm1, xmm2/m128, imm8
VPCMPISTRI xmm1, xmm2/m128, imm8
VPCMPISTRM xmm1, xmm2/m128, imm8