Instruction
VPXOR
Computes the bitwise XOR of two XMM or YMM sources into a separate destination (YMM with AVX2).
VPXOR computes the bitwise exclusive OR of two 128- or 256-bit values into a third register. It is the VEX form of PXOR, with a separate destination, a memory operand at any address and, for the 128-bit form, the bits from 128 up cleared. Like every bitwise operation it does not care about element boundaries, so one instruction serves bytes, words, doublewords and quadwords alike. AVX-512 has no EVEX VPXOR: VPXORD and VPXORQ are the same operation, differing only in the element size of the write mask.
Zeroing
vpxor xmm0, xmm0, xmm0 is the usual way to clear a vector register.
The result does not depend on the old value, which processors recognize
(see the page’s lines from the optimization guide), and the VEX encoding
clears the whole register: on Zen 5, vpxor xmm4, xmm4, xmm4 left all
512 bits of ZMM4 zero. GCC 14 at -O2 uses it for _mm256_setzero_si256
and even for the 512-bit _mm512_setzero_si512, since the short xmm
form clears a zmm register too, and for the accumulators of vectorized
sums. Clang 23 zeroes the accumulators the same way but uses
VXORPS for the two intrinsics.
Comparing and inverting
Both compilers use VPXOR for memcmp(p, q, 32) == 0 with
-march=x86-64-v3: a load, VPXOR with the other block as its memory
operand, then VPTEST of the result with itself and
SETE. For a[i] = b[i] ^ c[i] over unsigned arrays, GCC 14 emits VPXOR
and Clang 23 VXORPS, the same bits by another encoding. AVX2 has no NOT:
GCC and Clang invert a vector by XOR with all ones made by
VPCMPEQD of a register with itself; with
-march=x86-64-v4 both use VPTERNLOGQ instead, and
GCC switches the XOR of the loop to VPXORD on zmm registers.
AMD’s latency spreadsheet for Zen 5 gives VPXOR one cycle and four per cycle on any of the four vector pipes. 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 VPXOR, a line per claim. Each links to the claim in the guide, with its sources and where they differ.
Out of order
- Zeroing and dependency-breaking idioms: The vector registers have idioms of their own:
pxor,xorps,xorpd,pandn,andnps, the integer subtractionspsuband the comparisonspcmpgtof a register with itself, with their VEX and EVEX forms, which Intel counts for 512-bit registers only unmasked. sources differ
Zen 3
- Integer execution: Register-to-register moves of general registers of 32 and 64 bits,
xchgof them and moves of whole XMM and YMM registers take no execution cycle, nor do the zeroing idioms such asxor eax, eaxandvpxor, which also break the dependency on the old value;sbb eax, eaxdepends only on the carry flag, andpcmpeqd xmm0, xmm0sets all ones without waiting. sources differ
Zen 4
- Integer execution: Register-to-register moves of general registers of 32 and 64 bits,
xchgof them and moves of whole vector registers take no execution cycle, nor do the zeroing idioms such asxor eax, eaxandvpxor, which also break the dependency on the old value;sbb eax, eaxdepends only on the carry flag. sources differ
Zen 5
- Integer execution: Register-to-register moves of 32-bit and 64-bit general registers and of whole vector registers take no execution cycle, nor do the zeroing idioms such as
xor eax, eaxandvpxor, which also break the dependency on the old value.
Forms
| Instruction | Encoding | Requires |
|---|---|---|
VPXOR xmm, xmm, m128
VPXOR_XMMdq_XMMdq_MEMdq | VEX.128.66.0F.WIG EF /r | AVX |
VPXOR xmm, xmm, xmm
VPXOR_XMMdq_XMMdq_XMMdq | VEX.128.66.0F.WIG EF /r | AVX |
VPXOR ymm, ymm, m256
VPXOR_YMMqq_YMMqq_MEMqq | VEX.256.66.0F.WIG EF /r | AVX2 |
VPXOR ymm, ymm, ymm
VPXOR_YMMqq_YMMqq_YMMqq | VEX.256.66.0F.WIG EF /r | AVX2 |
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.
Every quadword works alike: 2 and 4 quadwords in the xmm and ymm forms.
Result quadword i comes from quadword i of xmm2 and xmm3. Result quadwords 1 to 0: a1^b1, a0^b0.
Operation
What the forms do, in pseudocode that our tests run against results recorded on real processors. How to read.
for i in range(VL // 64):
ymm1.q[i] = ymm2.q[i] ^ src3.q[i]
# ymm1 is zeroed from bit VL upRun on AMD Zen 5 (EPYC 9645): 4 cases.
Operands
| Operand | Kind | Action |
|---|---|---|
VPXOR xmm, xmm, xmm/m128 VPXOR ymm, ymm, ymm/m256 | ||
xmm, ymm | explicit | write |
xmm, ymm | explicit | read |
xmm/m128, ymm/m256 | 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-4
Intrinsics
The C intrinsics of Clang 23.1.2 that compile to VPXOR, 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_xor_epi32
__m128i _mm_xor_epi32(__m128i __a, __m128i __b) |
|
_mm_xor_epi64
__m128i _mm_xor_epi64(__m128i __a, __m128i __b) |
|
_mm_xor_pd
__m128d _mm_xor_pd(__m128d __a, __m128d __b) |
|
_mm_xor_si128
__m128i _mm_xor_si128(__m128i __a, __m128i __b) |
|
_mm256_xor_epi32
__m256i _mm256_xor_epi32(__m256i __a, __m256i __b) |
|
_mm256_xor_epi64
__m256i _mm256_xor_epi64(__m256i __a, __m256i __b) |
|
_mm256_xor_si256
__m256i _mm256_xor_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 |
AVX2 | AVX2 | 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, Zen, Zen+, Zen 2, Zen 3, Zen 4, Zen 5, Zen 6 |
More AVX instructions
- VPSRLDQ
- VPSRLQ
- VPSRLW
- VPSUBB
- VPSUBD
- VPSUBQ
- VPSUBSB
- VPSUBSW
- VPSUBUSB
- VPSUBUSW
- VPSUBW
- VPTEST
- VPUNPCKHBW
- VPUNPCKHDQ
- VPUNPCKHQDQ
- VPUNPCKHWD
- VPUNPCKLBW
- VPUNPCKLDQ
- VPUNPCKLQDQ
- VPUNPCKLWD
- VRCPPS
- VRCPSS
- VROUNDPD
- VROUNDPS
- VROUNDSD
- VROUNDSS
- VRSQRTPS
- VRSQRTSS
- VSHUFPD
- VSHUFPS
- VSQRTPD
- VSQRTPS
- VSQRTSD
- VSQRTSS
- VSTMXCSR
- VSUBPD
- VSUBPS
- VSUBSD
- VSUBSS
- VTESTPD
More AVX2 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-530 (PXOR)
- 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.