MOVDQU instruction (SSE2)

MOVDQU is the SSE2 load and store of 16 bytes at any address. Code uses it wherever it cannot prove that a pointer is a multiple of 16: string and memory functions, byte buffers, and vector loops over arrays that come from a caller. MOVDQA is the same move for aligned addresses only. Like MOVDQA, it leaves bits 128 and up of a destination register unchanged, and compilers often emit MOVUPS in its place, one byte shorter: at -O2, Clang 23 for both _mm_loadu_si128 and _mm_storeu_si128, and GCC 14 for the store.

The alignment rule of legacy SSE reaches beyond the moves: an instruction such as PADDD or PCMPEQB with a 16-byte memory operand faults on an unaligned address. Compilers therefore fold only loads they know to be aligned into such instructions, and load other data with MOVDQU first. The VEX encodings of AVX drop the rule, so there an unaligned load can be part of the arithmetic instruction. VMOVDQU is the VEX form, with 256 bits; the EVEX forms VMOVDQU8 to VMOVDQU64 add masking.

What costs time is crossing a cache line, not the instruction:

AMD’s Zen 5 guide states that on aligned data the aligned and unaligned instructions perform the same, and that loads and stores that span a 64-byte boundary run at half the throughput, with more for one that crosses a 4 KiB page.
Intel’s guide advises aligning the buffers that are stored to rather than those loaded from when only some can be aligned, because a store split across pages costs the most.

Two details differ between the manuals. With alignment checking on (CR0.AM and EFLAGS.AC at CPL 3), Intel’s says that a MOVDQU not aligned to 8 bytes may or may not raise #AC, depending on the processor, and AMD’s that one not aligned to 16 bytes raises it. And on processors with AVX, AMD’s makes any aligned 16-byte access atomic, Intel’s only those of the aligned moves such as MOVDQA, so portable code cannot count on MOVDQU being atomic.

In the optimization guide

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

Redwood Cove

Front end: Redwood Cove fuses a load into a register with the operation on that register that follows it.
Front end: Redwood Cove’s load-and-operate fusion takes only some loads, addresses and operations.

Silvermont to Goldmont Plus

Out-of-order and in-order execution: Goldmont eliminates register-to-register moves of XMM registers; Silvermont does not. sources differ
Loads, stores and caches: Unaligned vector loads are one micro-op, but line splits are slow; Intel suggests aligned loads and palignr.

Forms

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

Instruction	Encoding	Requires
`MOVDQU xmm, m128` MOVDQU_XMMdq_MEMdq	`F3 0F 6F /r`	SSE2
`MOVDQU xmm, xmm` MOVDQU_XMMdq_XMMdq_0F6F	`F3 0F 6F /r`	SSE2
`MOVDQU m128, xmm` MOVDQU_MEMdq_XMMdq	`F3 0F 7F /r`	SSE2
`MOVDQU xmm, xmm` MOVDQU_XMMdq_XMMdq_0F7F	`F3 0F 7F /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 move: each doubleword is copied to the same place.

The store forms copy the same way, from the register to memory.

Result doubleword i is doubleword i of xmm2. Result doublewords 3 to 0: a3, a2, a1, a0.

Operation

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

dest.write(src2.read())
# a register destination: bits 128 and up are unchanged

Run on AMD Zen 5 (EPYC 9645): 4 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
`MOVDQU xmm, xmm/m128`
`xmm`	explicit	write
`xmm/m128`	explicit	read
`MOVDQU xmm/m128, xmm`
`xmm/m128`	explicit	write
`xmm`	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: SSE_TYPE_4M

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