PINSRB instruction (SSE4.1)

PINSRB writes one byte, the low byte of a 32-bit general-purpose register or a byte of memory, into the element of an XMM register that bits 3:0 of the immediate pick, and keeps the other fifteen. PINSRD describes the family that SSE4.1 brought: the destination is also an input, and the memory form reads only its own bytes, at any address. On Zen 5, pinsrb xmm0, r9d, 0xb3 put 3Ch, the low byte of R9, into byte 3, and pinsrb xmm4, byte ptr [mem], 0xd6 put the byte from memory into byte 6; the upper four bits of each immediate were ignored, and bits 511:128 of the registers kept their values.

Before SSE4.1

SSE2 can insert words, with PINSRW, but not bytes. For v[5] = c on a vector of 16 chars, GCC 14 and Clang 23 at -O2 emit pinsrb xmm0, edi, 5 with -msse4.1, and the memory form when c comes from a pointer. For the x86-64 baseline they part ways: GCC stores the vector to the stack, writes the byte there and loads the vector back; Clang clears byte 5 with PAND, moves the byte into place with MOVD and PSLLQ by 40, and merges with PANDN and POR.

Many bytes, or an index in a register

Building a vector of 16 bytes loaded from scattered addresses, as in _mm_setr_epi8(p[0], p[3], ... p[45]), shows the two styles also seen with PINSRD. Clang starts with MOVZX and MOVD and inserts the other 15 bytes with PINSRB, one after another, each waiting for the last. GCC builds pairs of bytes in eight registers, each with a MOVZX and MOVD of one byte and a PINSRB of the next, and joins them with PUNPCKLWD, PUNPCKLDQ and PUNPCKLQDQ.

The index has to be known when the code is assembled. For v[i] = c with i in a register, Clang goes through the stack even with SSE4.1; GCC broadcasts both c and i to every byte with PSHUFB, compares i with the constant 0, 1 … 15 using PCMPEQB, and selects with PBLENDVB.

AMD’s latency spreadsheet for Zen 5 lists the register form as two macro-ops and the memory form as one. PEXTRB reads a byte out, and VPINSRB, the VEX and EVEX form, takes the other bytes from a separate source register and clears bits 128 and up.

Forms

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

Instruction	Encoding	Requires
`PINSRB xmm, m8, imm8` PINSRB_XMMdq_MEMb_IMMb	`66 0F 3A 20 /r ib`	SSE4.1
`PINSRB xmm, r32, imm8` PINSRB_XMMdq_GPR32d_IMMb	`66 0F 3A 20 /r ib`	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.

Insert: the byte from r32 replaces byte imm8 of xmm1; the rest of the result comes from xmm1.

Example: imm8 = 0x05.

With imm8 = 0x05, result bytes 15 to 0: a15, a14, a13, a12, a11, a10, a9, a8, a7, a6, b0, a4, a3, a2, a1, a0.

Operation

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

xmm1.b[imm8 & 15] = src2.b[0]  # the others keep their values
# 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
`PINSRB xmm, m8, imm8`
`xmm`	explicit	read, write
`m8`	explicit	read
`imm8`	explicit	read
`PINSRB xmm, r32, imm8`
`xmm`	explicit	read, write
`r32`	explicit	read
`imm8`	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_5

Intrinsics

The C intrinsics of Clang 23.1.2 that compile to PINSRB, 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_insert_epi8` `__m128i _mm_insert_epi8(__m128i X, int I, const int N)`	`PINSRB xmm, r32, imm8` 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

Before SSE4.1#

Many bytes, or an index in a register#