[Intel] EVEX broadcast operand size bug

[gnrkr789]

Issue

TestCraft detected an issue in the decoding of EVEX embedded-broadcast memory operands.

For a broadcast memory operand (m32bcst / m64bcst), the memory operand size should be the broadcast element size (32 or 64 bits), not the full destination vector width. B2R2 currently reports the vector width, so the decoded memory operand size is wrong.

Details

The main problems are:

• For an m64bcst source, the operand is a single 64-bit element broadcast across the vector. However, B2R2 reports the operand size as the vector width (ymmword/zmmword) instead of qword (64 bits). The same applies to m32bcst, which should be decoded as dword.
• The broadcast attribute itself is not reflected, so a broadcast operand is indistinguishable from a full-width vector load.

This issue was detected in 445 cases via TestCraft.

Example (VANDNPD ymm {k}{z}, ymm, ymm/m256/m64bcst, 62f1fdb9557508):

• objdump / capstone: qword ... {1to4}
  → element size 64 bits, broadcast reflected
• B2R2: ymmword ... {1to1}
  → size 256 bits, no broadcast information

Expected Behavior

A broadcast memory operand should decode with the broadcast element size:

• m32bcst -> 32-bit
• m64bcst -> 64-bit

It should also preserve the broadcast attribute according to the EVEX.b semantics.

Actual Behavior

The operand size is decoded as the full vector width, and the broadcast attribute is lost.

References

Intel SDM, EVEX encoding: the EVEX.b bit and the embedded-broadcast operand forms (m32bcst / m64bcst) in the per-instruction operand tables.

Detection

This issue was detected via TestCraft.