Instruction
VPTEST
Sets ZF if the AND of two XMM or YMM operands is all zeros and CF if the AND of the inverted first with the second is.
- Extensions
- Forms
- 4 (4 VEX)
- Data
- Intel XED v2026.08.23
VPTEST is PTEST in a VEX encoding: it ANDs two vectors
without keeping the result, sets ZF when the AND is all zeros and CF
when the second operand ANDed with the inverted first is all zeros, and
clears OF, SF, AF and PF. The PTEST page explains the two answers and
the intrinsics that read them. The VEX.256 form is what this page adds,
a test of 32 bytes at once; the VEX.128 form is PTEST with a memory
operand at any address. On Zen 5, vptest ymm8, ymm15 on two unrelated
values changed RFLAGS from A97h to 202h: CF, PF, AF, SF and OF were
cleared, and ZF, already clear, stayed so.
In compiled code
At -O2 with -march=x86-64-v3, GCC 14 and Clang 23 compile memcmp(p, q, 32) == 0 to a load, VPXOR with the other block in
memory, vptest ymm0, ymm0 and SETE, and _mm256_testz_si256(a, a) and
_mm256_testc_si256(a, b) to VPTEST and SETE or SETB. For 64 bytes the
two differ. Clang ORs the two XOR results with VPOR and tests once; GCC
tests each half and branches after the first. With -march=x86-64-v4,
Clang 23 keeps VPTEST and merges the second half with
VPTERNLOGQ, while GCC 14 compares the whole 64
bytes with VPCMPEQD into a mask register and tests
that with KORTESTW.
AVX-512 has no flag-setting test of a ZMM register: VPTEST stops at 256 bits, and VPTESTMD and its kin write a mask register instead. VTESTPS and VTESTPD are the VEX tests of sign bits only.
AMD’s latency spreadsheet for Zen 5 lists VPTEST as two macro-ops, on pipes 1 or 2 and 4 or 5, two per cycle. Zen 5’s 4 recorded cases cover the register and memory forms at both widths.
In the optimization guide
What the optimization guide says about VPTEST, a line per claim. Each links to the claim in the guide, with its sources and where they differ.
Crestmont and Gracemont
- Vectors and AVX2: The 256-bit vector tests take 7 cycles from the vectors to the flags.
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 ymm forms test all 256 bits.
ZF and CF each depend on every element of xmm1 and xmm2. RFLAGS: CF, ZF.
Operation
What the forms do, in pseudocode that our tests run against results recorded on real processors. How to read.
zf = ymm1.read() & src2.read() == 0
cf = ~ymm1.read() & src2.read() == 0
of = sf = af = pf = 0Run on AMD Zen 5 (EPYC 9645): 4 cases.
Operands
| Operand | Kind | Action |
|---|---|---|
VPTEST xmm, xmm/m128 VPTEST ymm, ymm/m256 | ||
xmm, ymm | explicit | read |
xmm/m128, ymm/m256 | explicit | read |
RFLAGS | implicit | write |
Flags
| ZF | CF |
|---|---|
| All forms | |
| M | M |
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-4
Intrinsics
The C intrinsics of Clang 23.1.2 that compile to VPTEST, 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_test_all_ones
int _mm_test_all_ones(__m128i V) |
|
_mm_test_all_zeros
int _mm_test_all_zeros(__m128i M, __m128i V) |
|
_mm_test_mix_ones_zeros
int _mm_test_mix_ones_zeros(__m128i M, __m128i V) |
|
_mm_testc_si128
int _mm_testc_si128(__m128i __M, __m128i __V) |
|
_mm_testnzc_si128
int _mm_testnzc_si128(__m128i __M, __m128i __V) |
|
_mm_testz_si128
int _mm_testz_si128(__m128i __M, __m128i __V) |
|
_mm256_testc_si256
int _mm256_testc_si256(__m256i __a, __m256i __b) |
|
_mm256_testnzc_si256
int _mm256_testnzc_si256(__m256i __a, __m256i __b) |
|
_mm256_testz_si256
int _mm256_testz_si256(__m256i __a, __m256i __b) |
|
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 2B, page 4-498 (PTEST)
- Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 1 (253665-093, September 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.