Instruction
PCMPEQQ
Compares packed quadwords for equality, into all-ones or all-zeros quadwords; SSE4.1.
- Extensions
- Forms
- 2 (2 Legacy)
- Data
- Intel XED v2026.08.23
PCMPEQQ compares the two quadwords of an XMM register with those of
another register or of memory and sets each destination quadword to all
ones where the two are equal and to zero where they differ. Equality
ignores signs, so it serves int64_t, uint64_t and pointers alike.
There is no MMX form. On Zen 5, the recorded pcmpeqq xmm8, xmm15 set
the low quadword, 8 in both registers, to FFFFFFFFFFFFFFFFh and cleared
the high one, 10h against 1, and left bits 255:128 of the register as
they were, like every legacy SSE instruction (see mixing SSE and
AVX).
Which extension
The SDM (Volume 2B, page 4-251) and AMD’s manual (Volume 4, page 304) both place PCMPEQQ in SSE4.1, under that CPUID bit, while its ordered partner PCMPGTQ came with SSE4.2. Intel’s optimization manual says otherwise in the introduction to its Chapter 6 (page 6-1), which names “PCMPEQQ in SSE4.2” among the SIMD integer instructions; the CPUID bit to test is SSE4.1’s. Both are part of x86-64-v2.
Without it
SSE2 compares doublewords only, so for a[i] = b[i] == c[i] ? -1 : 0
over int64_t, GCC 14 and Clang 23 at -O2 for the baseline compare with
PCMPEQD, swap the two halves of each quadword with
PSHUFD and AND the two results: a quadword is equal
when both of its halves are. With -march=x86-64-v2, both emit one
PCMPEQQ, and b[i] == c[i] ? 0 : b[i] adds just a
PANDN.
To count matches, n += b[i] == k, both at -v2 compare with PCMPEQQ
and gather the low doublewords of the results into doubleword counters:
Clang with PSHUFD and a subtraction of the all-ones results, GCC with a
PAND of 1 and SHUFPS. A loop that returns the index of the first match
stays scalar in both.
Comparing a register with itself sets it to all ones, and AMD’s Zen 5 guide lists the legacy PCMPEQB, PCMPEQW, PCMPEQD and PCMPEQQ with one register twice as ones idioms that do not wait for the old value (Section 2.9.2); compilers use PCMPEQD for it. The same guide’s latency spreadsheet gives PCMPEQQ two cycles at two per cycle, where PCMPEQD takes one at four per cycle. A memory operand must be aligned to 16 bytes. VPCMPEQQ is the VEX and EVEX form.
In the optimization guide
What the optimization guide says about PCMPEQQ, a line per claim. Each links to the claim in the guide, with its sources and where they differ.
Bulldozer to Excavator
- Integer execution:
xororsubof a 32-bit or 64-bit register with itself, and vector forms such aspxor,xorps,pandn,psubdorpcmpeqd, do not wait for the old value, though they still use a pipe, andsbb eax, eaxwaits only for the carry.
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.
Result quadword i comes from quadword i of xmm1 and xmm2. Result quadwords 1 to 0: r1, r0.
Operation
What the forms do, in pseudocode that our tests run against results recorded on real processors. How to read.
for i in range(2):
a = xmm1.q[i]
b = src2.q[i]
xmm1.q[i] = -1 if a == b else 0
# bits 128 and up of the register are unchangedRun on AMD Zen 5 (EPYC 9645): 2 cases.
Operands
| Operand | Kind | Action |
|---|---|---|
PCMPEQQ xmm, xmm/m128 | ||
xmm | explicit | read, write |
xmm/m128 | 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_4
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 PCMPEQQ, 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_cmpeq_epi64
__m128i _mm_cmpeq_epi64(__m128i __V1, __m128i __V2) |
|
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 |
|---|---|---|
SSE4 | SSE4.1 | Penryn, Nehalem, Westmere, 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, Silvermont, Goldmont, Goldmont Plus, Tremont, Snow Ridge, Lakefield, Sierra Forest, Clearwater Forest, Knights Landing, Knights Mill, K10 (Family 10h), Bulldozer, Piledriver, Zen, Zen+, Zen 2, Zen 3, Zen 4, Zen 5, Zen 6 Note: XED's AMD_K10 inherits everything from its Westmere chip, including SSSE3, SSE4.1, SSE4.2, AES-NI and PCLMULQDQ; GCC's -march=amdfam10 has none of them. |
More SSE4.1 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-251 (PCMPEQQ)
- 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.