MASKMOVDQU instruction (SSE2)

MASKMOVDQU stores some of the 16 bytes of its first operand: those whose byte in the second operand has its top bit set. The address is not an operand at all: the store goes to DS:RDI, or DS:EDI with a 67h prefix, like a string instruction’s, and a segment prefix can replace DS. It need not be aligned. The mask format is the one PMOVMSKB reads and PCMPGTB or PCMPEQB produce, so a compare result can serve directly. VMASKMOVDQU is the VEX form, also 16 bytes only; MASKMOVQ is the 8-byte MMX one.

A non-temporal store

Unlike VMASKMOVPS and the AVX-512 masked moves, MASKMOVDQU is a streaming store: both vendors’ manuals say it goes through write-combining buffers and is weakly ordered, and Intel’s adds that it should not read the line for ownership first. So it brings the costs and rules of the other non-temporal stores, which the optimization guide’s memory chapter sets out: data that is read again soon misses in the cache, and other threads may see the bytes late unless an SFENCE or MFENCE comes before the store that publishes them. Intel’s optimization manual lists it with MOVNTDQ and the other streaming stores (Section 9.4.1). Lines left partly written are the expensive case for write combining, and a store that skips bytes leaves its line that way.

Faults and the mask

The bytes left out are not written, but both manuals leave open whether they can still fault: Intel’s says that with an all-zero mask, page faults and breakpoints may or may not be signaled, AMD’s says the same of every unselected byte. Zen 5’s recorded cases show the address rules: an all-zero mask left memory untouched, an odd address worked, a non-canonical RDI raised #GP, and with a 67h prefix only the low 32 bits of RDI were used.

In practice

_mm_maskmoveu_si128(data, mask, p) makes GCC 14 and Clang 23 move p into RDI, since the instruction cannot take it elsewhere, and both emit VMASKMOVDQU once AVX is on. Neither uses it at -O2 for a loop such as if (c[i] < 0) a[i] = b[i]. AMD’s Zen 5 guide lists both forms as microcoded.

In the optimization guide

What the optimization guide says about MASKMOVDQU, a line per claim. Each links to the claim in the guide, with its sources and where they differ.

Jaguar and Puma

Vectors and floating point: AMD’s spreadsheet gives a VMASKMOVPS load the 6 cycles of a load-op, one per 128 bits, and lists MASKMOVDQU as microcoded; LLVM’s model gives MASKMOVDQU 34 cycles and 63 micro-ops. sources differ

Forms

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

Instruction	Encoding	Requires
`MASKMOVDQU xmm, xmm` MASKMOVDQU_XMMxub_XMMxub	`66 0F F7 /r`	SSE2

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.

A masked store: each byte moves where the sign bit of the byte in the same place of xmm2 is 1; elsewhere memory is left as it was.

Example sign bits of xmm2: 10110010. Shown: bytes 7 to 0. Every byte works alike: 16 bytes in the xmm form.

Result bytes 7 to 0: a7, unchanged, a5, a4, unchanged, unchanged, a1, unchanged.

Operation

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

a = aDI                          # DS:rDI, EDI with a 67 prefix
if not canonical(a):
    fault(GP, 0)                 # even with no byte selected
for i in range(16):              # checked whatever the mask: Zen
    if not writable(a + i):      # 5 faulted at an unmapped rDI
        fault(PF)                # with no byte selected
for i in range(16):
    if xmm2.b[i] >> 7:           # the top bit of each byte selects it
        store(a + i, 8, xmm1.b[i])
# a segment prefix (FS, GS) adds its base to the address

Run on AMD Zen 5 (EPYC 9645): 10 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
`MASKMOVDQU xmm, xmm`
`xmm`	explicit	read
`xmm`	explicit	read
`m128 at [rDI]`	implicit	write
`rDI`	implicit	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: SSE_TYPE_4

Attributes

What else XED records about the forms. How to read.

All forms: non-temporal hint; may abort a TSX transaction

Intrinsics

The C intrinsics of Clang 23.1.2 that compile to MASKMOVDQU, 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.

Intrinsic	Compiles to
`_mm_maskmoveu_si128` `void _mm_maskmoveu_si128(__m128i __d, __m128i __n, char *__p)`	`MASKMOVDQU xmm, xmm` Legacy -msse2

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
`SSE2` SSE2	SSE2 `CPUID.01H:EDX[26]` SSE2	Every x86-64 processor in XED’s model and Zen 3 to Zen 6

More SSE2 instructions

All 124 SSE2 instructions

A non-temporal store#

Faults and the mask#

In practice#