Instruction
MOVAPD
Moves packed doubles between XMM registers and memory, which must be aligned to 16 bytes.
- Extensions
- Forms
- 4 (4 Legacy)
- Data
- Intel XED v2026.08.23
MOVAPD copies 16 bytes between XMM registers, or between an XMM register and memory aligned to 16 bytes, read as two doubles but not interpreted. It is MOVAPS with a 66 prefix, which came with SSE2: the same alignment fault, the same two register encodings (0F 28 and 0F 29 after the prefix, both run on Zen 5) and the same atomicity of aligned accesses that MOVDQA describes. AMD’s manual makes the fault independent of its misaligned SSE mode, as for MOVDQA. VMOVAPD is the VEX and EVEX form, which clears the register above the vector and masks by double. The legacy load leaves bits 128 and up as they were (see mixing SSE and AVX).
A byte for a name
The prefix buys nothing in the result, and Intel’s optimization manual recommends the PS form, a byte shorter, wherever the two do the same (Section 3.5.1.10). The same manual names MOVAPD in its rule against copying a register with MOVSD, which writes only the low double and so waits for the rest of the old value: copy all 128 bits instead (Section 3.5.2.6, Rule 39).
Compilers follow the data. In our builds at -O2, with the default
target and with -march=x86-64-v2:
- GCC 14 copies
doublevalues and__m128dvectors between registers with MOVAPD, as indouble f(double a, double b) { return b; }, loads aligned arrays of doubles and_mm_load_pdwith it, but stores them with MOVAPS. - Clang 23 uses MOVAPD for the loads and stores of a loop over aligned
doublearrays and for a copy after a double-precision instruction such as SUBSD, while a plain copy is MOVAPS and so are_mm_load_pdand_mm_store_pd.
AMD’s Zen 5 guide, asking for loads and stores of the full register width, names VMOVAPD as the choice over MOVAPD (Section 2.11.2). Zen 5’s four recorded cases cover both register encodings and the aligned load and store.
In the optimization guide
What the optimization guide says about MOVAPD, 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.
Forms
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.
The store forms copy the same way, from the register to memory.
Result double i is double i of xmm2. Result doubles 1 to 0: 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 unchangedRun on AMD Zen 5 (EPYC 9645): 4 cases.
Operands
| Operand | Kind | Action |
|---|---|---|
MOVAPD xmm, xmm/m128 | ||
xmm | explicit | write |
xmm/m128 | explicit | read |
MOVAPD 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_1
Attributes
What else XED records about the forms. How to read.
- Memory forms
- aligned memory operand
Intrinsics
The C intrinsics of Clang 23.1.2 that compile to MOVAPD, 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_load_pd
__m128d _mm_load_pd(const double *__dp) |
|
_mm_store_pd
void _mm_store_pd(double *__dp, __m128d __a) |
|
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.
| ISA set | CPUID | Processors |
|---|---|---|
SSE2 | SSE2 | Every x86-64 processor in XED’s model and Zen 3 to Zen 6 |
More SSE2 instructions
Sources
- Intel XED v2026.08.23 (commit
0bcb6237345c): forms, encodings, operands, flags, exception classes, attributes, ISA sets, CPUID bits and chip model. - The CPU data of x86-64.net: Zen 3 to Zen 6, from GCC’s
-marchfeature sets and AMD’s Processor Programming References, which the page of each processor cites. - 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. - Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 2 (325383-093, September 2026): Volume 2B, page 4-37 (MOVAPD)
- Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 1 (253665-093, September 2026)
- AMD64 Architecture Programmer's Manual, Volume 4: 128-Bit and 256-Bit Media Instructions (26568, rev. 3.25, November 2021), Wayback Machine copy of AMD's PDF
- Intel 64 and IA-32 Architectures Optimization Reference Manual, Volume 1 (248966-051, October 2026)
- 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, part of the LLVM Project, licensed under the Apache License 2.0 with LLVM Exceptions. The text is our own.