VPBROADCASTMB2Q instruction (AVX10.1)

VPBROADCASTMB2Q copies the low 8 bits of a mask register, zero-extended, into every quadword of a vector register; the 56 bits above them are ignored. Its sibling VPBROADCASTMW2D copies the low 16 bits into every doubleword. Both came with AVX512CD, the conflict-detection extension of VPCONFLICTD, and are the only ones in it that take a mask register as their source. The recorded cases on Zen 5 copied C5h from a mask of 72B39A75A974B9C5h into all eight quadwords of a zmm register, and the xmm and ymm forms zeroed the register above their two or four.

Not VPMOVM2Q

VPMOVM2Q spreads a mask out: bit i becomes all ones or all zeros in element i. VPBROADCASTMB2Q keeps the bits together and gives each element the whole mask, which suits work done bit by bit inside an element. VPCONFLICTQ, for one, sets bit j of element i when element j below it holds the same value; ANDing that with the broadcast mask keeps only the conflicts with the elements the mask selects.

In compiled code

The instruction takes no write mask: EVEX.z and the mask field must be zero, or it raises #UD. The intrinsics are _mm512_broadcastmb_epi64 and _mm512_broadcastmw_epi32, with 128- and 256-bit versions under AVX512VL. With -march=znver5 at -O2, GCC 14 compiles the intrinsic to KMOVB and VPBROADCASTMB2Q, while Clang 23 moves the mask argument, which arrives in a general register, straight into VPBROADCASTQ. For a mask that a compare left in a mask register, _mm512_set1_epi64(_mm512_cmpeq_epi64_mask(x, y)), it is the other way round: Clang emits VPBROADCASTMB2Q, GCC a KMOVQ to a general register and VPBROADCASTQ, and the same holds for 16 bits and VPBROADCASTMW2D.

AMD’s Zen 5 guide lists both as one macro-op with a latency of 2 cycles.

Forms

Every encoding of VPBROADCASTMB2Q that Intel XED knows, one row per XED instruction form (iform). How to read the notation.

Instruction	Encoding	Requires
`VPBROADCASTMB2Q zmm, k` VPBROADCASTMB2Q_ZMMu64_MASKu64_AVX512CD	`EVEX.512.F3.0F38.W1 2A /r`	AVX10.1 or AVX512CD
`VPBROADCASTMB2Q xmm, k` VPBROADCASTMB2Q_XMMu64_MASKu64_AVX512	`EVEX.128.F3.0F38.W1 2A /r`	AVX10.1 or AVX512CD + AVX512VL
`VPBROADCASTMB2Q ymm, k` VPBROADCASTMB2Q_YMMu64_MASKu64_AVX512	`EVEX.256.F3.0F38.W1 2A /r`	AVX10.1 or AVX512CD + AVX512VL

Latency and throughput

What the scheduling models of LLVM 23.1.2 give for each form, not measurements: latency / reciprocal throughput in cycles, the ports under them. A row is a model, or models that agree; a dash, a form that its processors lack. Memory forms: latency from the address, ports without the load and store units. Which processors each model covers.

Model	`zmm, k` `xmm, k` `ymm, k`
Skylake-SP, Ice Lake	1 / 1p5
Sapphire Rapids	6 / 1p05
Zen 4	1 / 0.5¹FP1 FP2

Zen 4 model: AMD's spreadsheets give latency 2 for Zen 4 and Zen 5 (AMD 57647, row 2020; AMD 58455, row 527).

Data flow

Where the elements of the sources go, element 0 on the right; results that depend on a control value are drawn for an example. How to read.

Broadcast: the low 8 bits of k2, zero-extended, goes to every quadword of the result.

Shown for the zmm form; the xmm and ymm forms work the same on 2 and 4 quadwords.

Result quadwords 7 to 0: a0, a0, a0, a0, a0, a0, a0, a0.

Operation

What the forms do, in pseudocode that our tests run against results recorded on real processors. How to read.

x = k2.read() & 0xFF  # the low 8 bits
for i in range(VL // 64):
    zmm1.q[i] = x
# zmm1 is zeroed from bit VL up

Run on AMD Zen 5 (EPYC 9645): 3 cases.

Operands

What each form reads and writes, as Intel XED records it: the operands of its syntax, in order, and the implicit ones that the syntax does not name. How to read.

Operand	Kind	Action
`VPBROADCASTMB2Q xmm, k` `VPBROADCASTMB2Q ymm, k` `VPBROADCASTMB2Q zmm, k`
`xmm, ymm, zmm`	explicit	write
`k`	explicit	read

Flags

None: XED records no flag that the forms test or change.

Exceptions

The exception class is XED's name for the set of exception conditions that a form follows. How to read.

All forms: AVX512-E6NF

CPUID and processors

Each form belongs to an XED ISA set. A form can be used when the processor reports every CPUID bit of one of its ISA set's alternatives.

CPUID requirements and processors of the XED ISA sets above. Alternatives are separated by “or”; processors follow XED’s chip model, whose AMD processors end with Zen 2, and the CPU data of this site for Zen 3 to Zen 6.

ISA set CPUID Processors

ISA set	CPUID	Processors
`AVX512CD_512` AVX10.1	AVX10.1 `CPUID.(EAX=07H,ECX=1):EDX[19]` AVX10 `CPUID.(EAX=24H,ECX=0):EBX[7:0] ≥ 1` AVX10 version or AVX512CD `CPUID.(EAX=07H,ECX=0):EBX[28]` AVX512CD	Cannon Lake, Ice Lake (client), Tiger Lake, Nova Lake, Skylake-SP, Cascade Lake, Cooper Lake, Ice Lake (server), Sapphire Rapids, Emerald Rapids, Granite Rapids, Diamond Rapids, Knights Landing, Knights Mill, Zen 4, Zen 5, Zen 6
`AVX512CD_128` AVX10.1	AVX10.1 `CPUID.(EAX=07H,ECX=1):EDX[19]` AVX10 `CPUID.(EAX=24H,ECX=0):EBX[7:0] ≥ 1` AVX10 version or AVX512CD + AVX512VL `CPUID.(EAX=07H,ECX=0):EBX[28]` AVX512CD `CPUID.(EAX=07H,ECX=0):EBX[31]` AVX512VL	Cannon Lake, Ice Lake (client), Tiger Lake, Nova Lake, Skylake-SP, Cascade Lake, Cooper Lake, Ice Lake (server), Sapphire Rapids, Emerald Rapids, Granite Rapids, Diamond Rapids, Zen 4, Zen 5, Zen 6
`AVX512CD_256` AVX10.1	Same as `AVX512CD_128`	Same as `AVX512CD_128`

AVX512CD_512