PBLENDVB instruction (SSE4.1)

PBLENDVB merges two vectors byte by byte under a mask: where the top bit of a mask byte is set, the result takes the source’s byte, and elsewhere it keeps the destination’s. Only bit 7 of each mask byte counts, so the mask can be the all-ones or all-zeros bytes of a comparison such as PCMPEQB or PCMPGTB, or plain data whose sign bits do the choosing. It is the vector form of c ? x : y.

XMM0, always

The legacy encoding names only two registers, so the mask is always XMM0, an implied operand that Intel’s manual writes as <XMM0> and GCC and Clang print as a third operand. Compilers have to steer every mask into XMM0: compiling a byte select with -msse4.1, Clang 23 at -O2 copies a second mask into XMM0 with MOVDQA before its second PBLENDVB in each iteration. In _mm_blendv_epi8(a, b, mask), the bytes of b win where the mask is set.

Before and after SSE4.1

SSE2 code blends with three logic instructions: it ANDs the mask with one value (PAND), ANDs its complement with the other (PANDN) and ORs the two (POR). That is what GCC 14 at -O2 emits for r[i] = c[i] < 0 ? p[i] : q[i] over bytes for the baseline; with -msse4.1 the three become one PBLENDVB. GCC still computes the mask with PCMPGTB against zero, although the sign bits of c alone would do.

VPBLENDVB, the VEX form of AVX and AVX2, names the mask as a fourth register operand, ends the XMM0 restriction and does not overwrite either source. AVX-512 has no EVEX form; it selects under a mask register with VPBLENDMB or with masking on any instruction. PBLENDW takes its choice from an immediate, and BLENDVPS and BLENDVPD use the top bit of each doubleword or quadword.

AMD’s guide for Zen 5 lists byte blends among the operations of the vector shuffle unit, beside packs and unpacks (Section 2.11.1). The legacy form needs a memory operand aligned to 16 bytes.

Forms

Every encoding of PBLENDVB that Intel XED knows, one row per XED instruction form (iform). How to read the notation.

Instruction	Encoding	Requires
`PBLENDVB xmm, m128` PBLENDVB_XMMdq_MEMdq	`66 0F 38 10 /r`	SSE4.1
`PBLENDVB xmm, xmm` PBLENDVB_XMMdq_XMMdq	`66 0F 38 10 /r`	SSE4.1

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.

Blend by vector: each byte comes from xmm2 where the sign bit of the byte in the same place of XMM0 is 1, else from xmm1.

Example sign bits of XMM0: 0000000010110010.

Result bytes 15 to 0: a15, a14, a13, a12, a11, a10, a9, a8, b7, a6, b5, b4, a3, a2, b1, a0.

Operation

What the forms do, in pseudocode that our tests run against results recorded on real processors. How to read.

for i in range(16):
    if xmm0.b[i] >> 7:
        xmm1.b[i] = src2.b[i]
    else:
        xmm1.b[i] = xmm1.b[i]
# xmm0.b[i] >> 7: the sign bit of the element
# bits 128 and up of the register are unchanged

Run on AMD Zen 5 (EPYC 9645): 2 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.

Operand	Kind	Action
`PBLENDVB xmm, xmm/m128`
`xmm`	explicit	read, write
`xmm/m128`	explicit	read
`XMM0`	implicit	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 PBLENDVB, 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_blendv_epi8` `__m128i _mm_blendv_epi8(__m128i __V1, __m128i __V2, __m128i __M)`	`PBLENDVB xmm, xmm` Legacy -msse4.1

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.

ISA set	CPUID	Processors
`SSE4` SSE4.1	SSE4.1 `CPUID.01H:ECX[19]` 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

All 49 SSE4.1 instructions

XMM0, always#

Before and after SSE4.1#