x86-64.net

Instruction

KMOVB

Moves an 8-bit mask between mask registers, general-purpose registers and memory; APX adds EVEX forms that reach the extended general-purpose registers.

Extensions
Forms
10 (5 VEX, 5 EVEX)
Data
Intel XED v2026.08.23

KMOVB moves the low 8 bits of a mask register: to or from another mask register, a byte of memory or a 32-bit general-purpose register. Eight bits are one per element of a ZMM register of quadwords or doubles, or of a YMM register of doublewords, so __mmask8 is the mask type of most AVX-512 code on 64-bit elements. KMOVB came with AVX512DQ; KMOVW, the only mask move of AVX-512F, describes the family. A mask register destination gets bits 63:8 cleared, and a general-purpose one the byte zero-extended to 64 bits: on Zen 5, kmovb ecx, k2 with K2 all ones left RCX = FFH, and kmovb k2, ecx took FFH from an ECX of all ones.

With and without AVX512DQ

With only -mavx512f, GCC 14 and Clang 23 at -O2 move eight-bit masks with KMOVW. Counting the elements that _mm512_cmp_pd_mask selects is then KMOVW, a MOVZX of AL and POPCNT, and storing the mask is KMOVW to EAX and a byte store. With AVX512DQ, as in -march=x86-64-v4, KMOVB does both in one step: kmovb eax, k0 needs no MOVZX before POPCNT, since it clears everything above bit 7, and kmovb byte ptr [rdi], k0 stores the byte directly. Clang also loads a stored mask with kmovb k1, byte ptr [rdi], where GCC loads it with MOVZX and moves it over. To return a compare’s mask, Clang still uses KMOVW (KMOVD with x86-64-v4), since a compare of eight elements clears the mask bits above 7 anyway; GCC uses KMOVB.

A mask for the last elements

For the last n of eight doubles, the mask is the low n bits set. GCC builds (1 << n) - 1 with a shift and a subtraction and moves it in with KMOVB; Clang shifts all ones left by n, inverts AL and moves it in with KMOVW. A zero-masked VMOVUPD then loads only those elements, and the ones the mask leaves out cannot fault.

AMD’s Zen 5 guide lists kmovb k, r32 as two macro-ops with a latency of two cycles and kmovb r32, k as one with a latency of one, the same as for KMOVQ. APX adds EVEX encodings whose general-purpose forms reach R16 to R31; Zen 5 has no APX, so they were not run.

Forms

Every encoding of KMOVB that Intel XED knows, one row per XED instruction form (iform). How to read the notation.
InstructionEncodingRequires
KMOVB k, k KMOVB_MASKmskw_MASKu8_AVX512VEX.LZ.66.0F.W0 90 /rAVX10.1 or AVX512DQ
KMOVB k, m8 KMOVB_MASKmskw_MEMu8_AVX512VEX.LZ.66.0F.W0 90 /rAVX10.1 or AVX512DQ
KMOVB m8, k KMOVB_MEMu8_MASKmskw_AVX512VEX.LZ.66.0F.W0 91 /rAVX10.1 or AVX512DQ
KMOVB k, r32 KMOVB_MASKmskw_GPR32u32_AVX512VEX.LZ.66.0F.W0 92 /rAVX10.1 or AVX512DQ
KMOVB r32, k KMOVB_GPR32u32_MASKmskw_AVX512VEX.LZ.66.0F.W0 93 /rAVX10.1 or AVX512DQ
KMOVB k, k KMOVB_MASKmskw_MASKu8_APXEVEX.LLZ.66.0F.W0 90 /rAVX10.1 + APX_F or APX_F + AVX512DQ
KMOVB k, m8 KMOVB_MASKmskw_MEMu8_APXEVEX.LLZ.66.0F.W0 90 /rAVX10.1 + APX_F or APX_F + AVX512DQ
KMOVB k, r32 KMOVB_MASKmskw_GPR32u32_APXEVEX.LLZ.66.0F.W0 92 /rAVX10.1 + APX_F or APX_F + AVX512DQ
KMOVB r32, k KMOVB_GPR32u32_MASKmskw_APXEVEX.LLZ.66.0F.W0 93 /rAVX10.1 + APX_F or APX_F + AVX512DQ
KMOVB m8, k KMOVB_MEMu8_MASKmskw_APXEVEX.LLZ.66.0F.W0 91 /rAVX10.1 + APX_F or APX_F + AVX512DQ

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.
Modelk, kk, m8m8, kk, r32r32, k
Skylake-SP1 / 1p07 / 1p01561 / 1p23471 / 1p53 / 1p0
Ice Lake1 / 1p07 / 1p01561 / 0.5p47891 / 1p53 / 1p0
Sapphire Rapids1 / 1p07 / 1p513 / 0.5p47893 / 1p53 / 1p0
Zen 41 / 0.5FP2 FP35 / 0.33AGU0 AGU1 AGU2 LSU Load1 / 0.5FP451 / 0.51FP451 / 0.5FP2 FP3
  1. Zen 4 model: AMD's spreadsheets give reciprocal throughput 1 for Zen 4 and Zen 5 (AMD 57647, row 332; AMD 58455, row 975).

Operation

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

v = low(src, 8)                  # a mask register or r32: the bits
                                 # above 7 are ignored
dest.write(v)                    # a mask register: bits 63:8 cleared;
                                 # r32: bits 63:8 of its 64-bit
                                 # register cleared; m8: one byte
# the APX forms (EVEX) move the same way, and reach R16 to R31

Run on AMD Zen 5 (EPYC 9645): 22 cases. The APX forms were not run: none of these processors has APX.

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.
OperandKindAction
KMOVB k, k/m8
kexplicitwrite
k/m8explicitread
KMOVB m8, k
m8explicitwrite
kexplicitread
KMOVB k, r32
kexplicitwrite
r32explicitread
KMOVB r32, k
r32explicitwrite
kexplicitread

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.

KMOVB k, k/m8 KMOVB m8, k
AVX512-K21
KMOVB k, r32 KMOVB r32, k
AVX512-K20
EVEX forms
APX-EVEX-KMOV

Intrinsics

The C intrinsics of Clang 23.1.2 that compile to KMOVB, each with the form it compiles to and the Clang options it needs. The forms come from compiling every intrinsic and decoding the result with Intel XED; all intrinsics A–Z explains the method.

IntrinsicCompiles to
_load_mask8 __mmask8 _load_mask8(__mmask8 *__A)

KMOVB k, m8 VEX.LZ -mavx512dq

_store_mask8 void _store_mask8(__mmask8 *__A, __mmask8 __B)

KMOVB m8, k VEX.LZ -mavx512dq

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 setCPUIDProcessors
AVX512DQ_KOPB

AVX10.1
CPUID.(EAX=07H,ECX=1):EDX[19] AVX10
CPUID.(EAX=24H,ECX=0):EBX[7:0] ≥ 1 AVX10 version

or

AVX512DQ
CPUID.(EAX=07H,ECX=0):EBX[17] AVX512DQ

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
APX_F_KOPB

AVX10.1 + APX_F
CPUID.(EAX=07H,ECX=1):EDX[21] APX_F
CPUID.(EAX=07H,ECX=1):EDX[19] AVX10
CPUID.(EAX=24H,ECX=0):EBX[7:0] ≥ 1 AVX10 version

or

APX_F + AVX512DQ
CPUID.(EAX=07H,ECX=1):EDX[21] APX_F
CPUID.(EAX=07H,ECX=0):EBX[17] AVX512DQ

Nova Lake, Diamond Rapids

More AVX10.1 instructions

All 686 AVX10.1 instructions

More APX instructions

All 88 APX instructions

Sources

  1. Intel XED v2026.08.23 (commit 0bcb6237345c): forms, encodings, operands, flags, exception classes, attributes, ISA sets, CPUID bits and chip model.
  2. The CPU data of x86-64.net: Zen 3 to Zen 6, from GCC’s -march feature sets and AMD’s Processor Programming References, which the page of each processor cites.
  3. Clang's x86 intrinsic headers, LLVM 23.1.2 (commit 85ac56026243): the intrinsics, their signatures and doc comments, and the Clang of that release, which compiled each of them.
  4. LLVM 23.1.2's x86 scheduling models (commit 85ac56026243): the latency, reciprocal throughput and ports of each form, as llvm-mca reports them.
  5. Intel Advanced Vector Extensions 10.2 Architecture Specification, revision 7.0 (361050-007, April 2026)
  6. Intel Advanced Performance Extensions (Intel APX) Architecture Specification, revision 9.0 (355828-009, August 2026)
  7. Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 2 (325383-093, September 2026): Volume 2A, page 3-517 (KMOVW/KMOVB/KMOVQ/KMOVD)
  8. Software Optimization Guide for the AMD Zen5 Microarchitecture (58455, rev. 1.00, August 2024), Wayback Machine copy of AMD's ZIP

The tables are derived from Intel XED, Copyright Intel Corporation, licensed under the Apache License 2.0; x86-64.net converted and reformatted them. The intrinsics and their signatures come from Clang and the timings from LLVM's scheduling models, both part of the LLVM Project, licensed under the Apache License 2.0 with LLVM Exceptions. The text is our own.