Instruction
PEXT
Extracts the bits of the source at the positions selected by a mask and packs them into the low bits of the destination.
PEXT gathers the bits of its source that sit where a mask has a 1 and packs them, in order, into the low bits of the destination; the bits above them are cleared. From 0xB4, the mask 0xF0 extracts 0xB, and the mask 0x81 extracts 0b10: bit 0 of the source, then bit 7. PDEP does the reverse, so PDEP of PEXT(x, m) with the same mask gives back x AND m.
Operand order
As in PDEP, the source comes second and the mask third:
pext rax, rbx, rcx gathers the bits of RBX selected by RCX, and only
the mask may be in memory. The intrinsics _pext_u32(src, mask) and
_pext_u64(src, mask) follow that order. There are 32- and 64-bit
forms, no 16-bit one, and no flag changes.
Uses
- Fields of any shape in one step:
_pext_u64(x, 0x8080808080808080)collects the top bit of each byte, the 8-bit mask that PMOVMSKB gives for a vector register. - Packing selected elements: widen an 8-bit selection m to a byte mask with PDEP (the PDEP page shows how), and PEXT of the index list 0x0706050403020100 under that mask packs the indices of the selected bytes at the bottom. For m = 0b10100110 that gives 0x07050201, a control for a byte shuffle such as PSHUFB that moves the selected elements together.
- A contiguous field needs no PEXT: a shift and an AND, or
BEXTR, do the same. Clang 23 at -O2 knows this and
compiles
_pext_u32(p, 0x07E0)toshr eax, 5andand eax, 63; GCC 14 keeps the PEXT with the mask in a register.
Neither compiler emits PEXT for a bit-gathering loop written in plain C; the intrinsics are the way to it.
Speed
AMD’s Zen 5 guide says Zen 5 runs PDEP and PEXT natively in three of its six integer ALUs, three per cycle with a latency of three cycles (Section 2.10.2), and its instruction table lists PEXT as one macro-op. The guide also tells software with separate code for fast and slow PDEP and PEXT to take the fast code on Zen 5: processors differ here, and code that depends on PEXT for speed should measure on the processors it targets.
PEXT belongs to BMI2, part of x86-64-v3; APX adds an EVEX form that reaches its new registers.
In the optimization guide
What the optimization guide says about PEXT, a line per claim. Each links to the claim in the guide, with its sources and where they differ.
Golden Cove and Raptor Cove
- Integer execution: Port 1 alone runs the slower integer operations: multiplication, PDEP and PEXT,
popcnt,bsr,crc32and the double shifts with an immediate count, which LLVM’s models give a latency of three cycles and one per cycle.
Skylake to Cooper Lake
- Integer execution: Port 1 alone runs integer multiplication, PDEP and PEXT,
popcnt,lzcnt,tzcnt,bsf,bsrand the double shifts, with a latency of three cycles and one a cycle in LLVM’s models, as on Golden Cove.
Zen and Zen+
- Integer execution: PDEP and PEXT are microcoded, in AMD’s spreadsheet and in LLVM’s model, though the core supports BMI2; code with a choice uses shifts and masks instead.
Zen 2
- Integer execution: PDEP and PEXT are microcoded, as in LLVM’s model, though CPUID reports BMI2; Zen 3 runs them on an ALU in three cycles.
Zen 3
- Integer execution: PDEP and PEXT run natively on ALU 1, one per cycle with a latency of three cycles; code with a separate path for processors where they are slow, such as Zen 2, should take the fast path.
Zen 4
- Integer execution: PDEP and PEXT run natively on one ALU, one per cycle with a latency of three cycles, against three per cycle on Zen 5; code with a separate path for processors where they are slow should take the fast path.
Zen 5
- Integer execution: PDEP and PEXT run natively, three per cycle with a latency of three cycles; code with a separate path for processors where they are slow should take the fast path.
Forms
| Instruction | Encoding | Requires |
|---|---|---|
PEXT r32, r32, m32
PEXT_GPR32d_GPR32d_MEMd | VEX.LZ.F3.0F38.W0 F5 /r | BMI2 |
PEXT r32, r32, r32
PEXT_GPR32d_GPR32d_GPR32d | VEX.LZ.F3.0F38.W0 F5 /r | BMI2 |
PEXT r64, r64, m64 64-bit mode only
PEXT_GPR64q_GPR64q_MEMq | VEX.LZ.F3.0F38.W1 F5 /r | BMI2 |
PEXT r64, r64, r64 64-bit mode only
PEXT_GPR64q_GPR64q_GPR64q | VEX.LZ.F3.0F38.W1 F5 /r | BMI2 |
PEXT r32, r32, r32
PEXT_GPR32i32_GPR32i32_GPR32i32_APX | EVEX.LLZ.F3.0F38.W0 F5 /r | APX_F + BMI2 |
PEXT r32, r32, m32
PEXT_GPR32i32_GPR32i32_MEMi32_APX | EVEX.LLZ.F3.0F38.W0 F5 /r | APX_F + BMI2 |
PEXT r64, r64, r64
PEXT_GPR64i64_GPR64i64_GPR64i64_APX | EVEX.LLZ.F3.0F38.W1 F5 /r | APX_F + BMI2 |
PEXT r64, r64, m64
PEXT_GPR64i64_GPR64i64_MEMi64_APX | EVEX.LLZ.F3.0F38.W1 F5 /r | APX_F + BMI2 |
Latency and throughput
| Model | r32, r32, m32r64, r64, m64 | r32, r32, r32r64, r64, r64 |
|---|---|---|
| Haswell, Broadwell, Skylake, Skylake-SP, Ice Lake, Alder Lake, Sapphire Rapids | 8 / 1p1 | 3 / 1p1 |
| Lunar Lake | 7 / 1.33p135 | 3 / 1p135 |
| Zen, Zen 2 | 100 / 0.25 | 100 / 0.25 |
| Zen 3, Zen 4 | 5 / 0.33ALU0 ALU1 ALU2 ALU3 | 3 / 1ALU1 |
Operation
What the forms do, in pseudocode that our tests run against results recorded on real processors. How to read.
s = src.read()
m = mask.read()
r = 0
k = 0 # the next bit of the result, from bit 0 up
for i in range(OSIZE):
if m >> i & 1:
r |= (s >> i & 1) << k # the bits of src where mask has a 1,
k += 1 # packed together
dest.write(r) # a 32-bit register: bits 63:32 cleared
Run on AMD Zen 5 (EPYC 9645): 36 cases. The APX forms were not run: none of these processors has APX.
Operands
| Operand | Kind | Action |
|---|---|---|
PEXT r32, r32, r/m32 PEXT r64, r64, r/m64 64-bit mode only | ||
r32/64 | explicit | write |
r32/64 | explicit | read |
r/m32/64 | 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.
- VEX forms
- none in XED
- EVEX forms
APX-EVEX-BMI
Intrinsics
The C intrinsics of Clang 23.1.2 that compile to PEXT, 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 |
|---|---|
_pext_u32
unsigned int _pext_u32(unsigned int __X, unsigned int __Y) |
|
_pext_u64
unsigned long long _pext_u64(unsigned long long __X, unsigned long long __Y) |
|
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 |
|---|---|---|
BMI2 | BMI2 | 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 |
APX_F_BMI2 | APX_F + BMI2 | Nova Lake, Diamond Rapids |
More BMI2 instructions
More APX 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. - LLVM 23.1.2's x86 scheduling models (commit
85ac56026243): the latency, reciprocal throughput and ports of each form, as llvm-mca reports them. - Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 2 (325383-093, September 2026): Volume 2B, page 4-284 (PEXT)
- Intel Advanced Performance Extensions (Intel APX) Architecture Specification, revision 9.0 (355828-009, August 2026)
- AMD64 Architecture Programmer's Manual, Volume 3: General-Purpose and System Instructions (24594, rev. 3.39, 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 and the timings from LLVM's scheduling models, both part of the LLVM Project, licensed under the Apache License 2.0 with LLVM Exceptions. The text is our own.