Instruction
VMASKMOVPS
Loads or stores packed singles only where the sign bit of the matching mask element is set; in Intel's manual, masked-off elements cannot fault.
- Extensions
- Forms
- 4 (4 VEX)
- Data
- Intel XED v2026.08.23
VMASKMOVPS moves singles between memory and a vector register only where a mask says so. The mask is a second XMM or YMM register, and only the sign bit of each of its elements counts, so the result of a compare such as VCMPPS can be used as it is. A load writes zero where the mask bit is clear; a store leaves the memory there untouched. There is no form between two registers, which is VBLENDVPS’s job, and, unlike MASKMOVDQU, no non-temporal hint.
Faults on masked-off elements
Intel’s manuals promise that no fault comes from an element whose mask bit is clear: an all-zero mask cannot fault at all, whatever the address. That makes it tempting for loop tails that would otherwise read past the end of an array. AMD’s manual, Volume 4, does not promise it: the exception and trap behavior of the elements left out is implementation-dependent, and a processor may report a page fault or a data breakpoint for them. Code meant for both should keep the masked-off part of the access on mapped memory. With AVX-512, a masked VMOVUPS with a mask register does the same job; Intel’s optimization manual notes that an all-zero mask there ignores faults without an assist (Table 17-2).
Cost
Intel’s optimization manual advises VMASKMOV only where a plain VMOVUPS cannot do the job (Section 15.9). A masked load whose masked-off part covers an address that would fault, or with an all-zero mask even a legal address in some addressing forms such as [base+index], can take an assist of hundreds of cycles; since Skylake, so can a store with an all-zero mask to an address that would fault. A load that reads what a masked store wrote waits for the store to reach the cache unless the mask is all ones or all zeros.
In compiled code
With -mavx2, GCC 14 at -O2 vectorizes if (c[i] > 0) a[i] = b[i]
over floats with VCMPLTPS, a VPTEST that skips blocks
where no element qualifies, and a VMASKMOVPS load and store; Clang 23
emits the same masked moves without the skip. Intel’s optimization
manual also uses the masked store to write a left-packed vector before
AVX-512’s compress existed (Section 17.5.1, Example 17-11).
VMASKMOVPD is the version for doubles and
VPMASKMOVD the AVX2 one for doublewords.
In the optimization guide
What the optimization guide says about VMASKMOVPS, a line per claim. Each links to the claim in the guide, with its sources and where they differ.
Vectors
- Masks and masked memory access: AVX’s VMASKMOV loads and stores can take assists of hundreds of cycles on Intel’s cores and are slow stores on Zen 3 and Zen 4.
Crestmont and Gracemont
- Vectors and AVX2: Masked loads and stores run one every two cycles on 256 bits, slower when a masked-off element would fault.
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
Skylake to Cooper Lake
- Loads, stores and caches: Loads after a
vmaskmovstore no longer wait for its mask to be known.
Zen 3
- Vectors and floating point: LLVM’s model makes a 256-bit VMASKMOVPS store 42 macro-ops that hold the store pipe for 12 cycles, while the masked load is an ordinary load; Zen 3 has none of the AVX-512 stores under a mask register that are ordinary stores on Zen 4.
Zen 4
- Vectors and floating point: LLVM’s model makes a 256-bit VMASKMOVPS store 42 macro-ops that hold the store pipe for 12 cycles, while the masked load is an ordinary load, and so is an AVX-512 store under a mask register such as
vmovups [rdi]{k1}, ymm0.
Forms
| Instruction | Encoding | Requires |
|---|---|---|
VMASKMOVPS xmm, xmm, m128
VMASKMOVPS_XMMdq_XMMdq_MEMdq | VEX.128.66.0F38.W0 2C /r | AVX |
VMASKMOVPS ymm, ymm, m256
VMASKMOVPS_YMMqq_YMMqq_MEMqq | VEX.256.66.0F38.W0 2C /r | AVX |
VMASKMOVPS m128, xmm, xmm
VMASKMOVPS_MEMdq_XMMdq_XMMdq | VEX.128.66.0F38.W0 2E /r | AVX |
VMASKMOVPS m256, ymm, ymm
VMASKMOVPS_MEMqq_YMMqq_YMMqq | VEX.256.66.0F38.W0 2E /r | AVX |
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.
VMASKMOVPS xmm, xmm, m128 VMASKMOVPS ymm, ymm, m256Example sign bits of xmm2: 1011. Every single works alike: 4 and 8 singles in the xmm and ymm forms.
Result singles 3 to 0: a3, 0, a1, a0.
VMASKMOVPS m128, xmm, xmm VMASKMOVPS m256, ymm, ymmExample sign bits of xmm2: 1011. Every single works alike: 4 and 8 singles in the xmm and ymm forms.
Result singles 3 to 0: a3, unchanged, a1, a0.
Operation
What the forms do, in pseudocode that our tests run against results recorded on real processors. How to read.
VMASKMOVPS xmm, xmm, m128 VMASKMOVPS ymm, ymm, m256for i in range(VL // 32):
if ymm2.d[i] >> 31:
ymm1.d[i] = mem.d[i]
else:
ymm1.d[i] = 0
# ymm1 is zeroed from bit VL upRun on AMD Zen 5 (EPYC 9645): 2 cases.
VMASKMOVPS m128, xmm, xmm VMASKMOVPS m256, ymm, ymmfor i in range(VL // 32):
if ymm2.d[i] >> 31: # the sign bit of the element
mem.d[i] = ymm3.d[i]
# else: mem.d[i] is not writtenRun on AMD Zen 5 (EPYC 9645): 2 cases.
Operands
| Operand | Kind | Action |
|---|---|---|
VMASKMOVPS xmm, xmm, m128 VMASKMOVPS ymm, ymm, m256 | ||
xmm, ymm | explicit | write |
xmm, ymm | explicit | read |
m128/256 | explicit | read |
VMASKMOVPS m128, xmm, xmm VMASKMOVPS m256, ymm, ymm | ||
m128/256 | explicit | write |
xmm, ymm | explicit | read |
xmm, ymm | 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
avx-type-6
Intrinsics
The C intrinsics of Clang 23.1.2 that compile to VMASKMOVPS, 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_maskload_ps
__m128 _mm_maskload_ps(const float *__p, __m128i __m) |
|
_mm_maskstore_ps
void _mm_maskstore_ps(float *__p, __m128i __m, __m128 __a) |
|
_mm256_maskload_ps
__m256 _mm256_maskload_ps(const float *__p, __m256i __m) |
|
_mm256_maskstore_ps
void _mm256_maskstore_ps(float *__p, __m256i __m, __m256 __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 |
|---|---|---|
AVX | AVX | Sandy Bridge, Ivy Bridge, Haswell, Broadwell, Skylake, Comet Lake, Cannon Lake, Ice Lake (client), Tiger Lake, Alder Lake, Arrow Lake, Panther Lake, Nova Lake, Skylake-SP, Cascade Lake, Cooper Lake, Ice Lake (server), Sapphire Rapids, Emerald Rapids, Granite Rapids, Diamond Rapids, Sierra Forest, Clearwater Forest, Knights Landing, Knights Mill, Bulldozer, Piledriver, Zen, Zen+, Zen 2, Zen 3, Zen 4, Zen 5, Zen 6 |
More AVX 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 2C, page 5-416 (VMASKMOV)
- Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 1 (253665-093, September 2026)
- Intel 64 and IA-32 Architectures Optimization Reference Manual, Volume 1 (248966-051, October 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
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.