Extensions
Forms
4 (4 VEX)
Data
Intel XED v2026.08.23

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 subtractions psub and the comparisons pcmpgt of 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, xchg of them and moves of whole XMM and YMM registers take no execution cycle, nor do the zeroing idioms such as xor eax, eax and vpxor, which also break the dependency on the old value; sbb eax, eax depends only on the carry flag, and pcmpeqd xmm0, xmm0 sets all ones without waiting. sources differ

Zen 4

  • Integer execution: Register-to-register moves of general registers of 32 and 64 bits, xchg of them and moves of whole vector registers take no execution cycle, nor do the zeroing idioms such as xor eax, eax and vpxor, which also break the dependency on the old value; sbb eax, eax depends 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, eax and vpxor, which also break the dependency on the old value.

Forms

Every encoding of VPXOR that Intel XED knows, one row per XED instruction form (iform). How to read the notation.
InstructionEncodingRequires
VPXOR xmm, xmm, m128 VPXOR_XMMdq_XMMdq_MEMdqVEX.128.66.0F.WIG EF /rAVX
VPXOR xmm, xmm, xmm VPXOR_XMMdq_XMMdq_XMMdqVEX.128.66.0F.WIG EF /rAVX
VPXOR ymm, ymm, m256 VPXOR_YMMqq_YMMqq_MEMqqVEX.256.66.0F.WIG EF /rAVX2
VPXOR ymm, ymm, ymm VPXOR_YMMqq_YMMqq_YMMqqVEX.256.66.0F.WIG EF /rAVX2

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.

Element-wise: each quadword of the result comes from the quadword in the same place in each source.
VPXOR: element by elementResult quadword i comes from quadword i of xmm2 and xmm3. Result quadwords 1 to 0: a1^b1, a0^b0.01xmm2aa0^b0a1^b1xmm101xmm3or m128b

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 up

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.
OperandKindAction
VPXOR xmm, xmm, xmm/m128 VPXOR ymm, ymm, ymm/m256
xmm, ymmexplicitwrite
xmm, ymmexplicitread
xmm/m128, ymm/m256explicitread

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.

IntrinsicCompiles to
_mm_xor_epi32 __m128i _mm_xor_epi32(__m128i __a, __m128i __b)

VPXOR xmm, xmm, xmm VEX.128 -mavx512vl

_mm_xor_epi64 __m128i _mm_xor_epi64(__m128i __a, __m128i __b)

VPXOR xmm, xmm, xmm VEX.128 -mavx512vl

_mm_xor_pd __m128d _mm_xor_pd(__m128d __a, __m128d __b)

VPXOR xmm, xmm, xmm VEX.128 -mavxwith AVX enabled

_mm_xor_si128 __m128i _mm_xor_si128(__m128i __a, __m128i __b)

VPXOR xmm, xmm, xmm VEX.128 -mavxwith AVX enabled

_mm256_xor_epi32 __m256i _mm256_xor_epi32(__m256i __a, __m256i __b)

VPXOR ymm, ymm, ymm VEX.256 -mavx512vl

_mm256_xor_epi64 __m256i _mm256_xor_epi64(__m256i __a, __m256i __b)

VPXOR ymm, ymm, ymm VEX.256 -mavx512vl

_mm256_xor_si256 __m256i _mm256_xor_si256(__m256i __a, __m256i __b)

VPXOR ymm, ymm, ymm VEX.256 -mavx2

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.

More AVX instructions

All 253 AVX instructions

More AVX2 instructions

All 138 AVX2 instructions

Sources

  1. Intel XED v2026.08.23 (commit 0bcb6237345c): forms, encodings, operands, flags, exception classes, attributes, ISA sets, CPUID bits and chip model.
  2. The CPU data of x86-64.net: Zen 3 to Zen 6, from GCC’s -march feature sets and AMD’s Processor Programming References, which the page of each processor cites.
  3. 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.
  4. Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 2 (325383-093, September 2026): Volume 2B, page 4-530 (PXOR)
  5. Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 1 (253665-093, September 2026)
  6. 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.