PACKUSDW instruction (SSE4.1)

PACKUSDW narrows doublewords to unsigned words: each doubleword, read as a signed number, is clamped to 0..65535, and the destination’s elements fill the low half of the result, the source’s the high half. SSE2 had the unsigned pack only for words to bytes, PACKUSWB, and the signed one for doublewords, PACKSSDW; SSE4.1 added this fourth combination, with no MMX form. On Zen 5, packusdw xmm7, xmmword ptr [mem] turned 0000FFFFh and 00010000h into FFFFh, and FFFF7FFFh and 80000000h into 0, and kept bits 511:128 of ZMM7.

Signed input

As with every pack (Intel’s optimization manual, Section 6.4.3), the input is signed: a uint32_t of 2^31 or more counts as negative and gives 0, not FFFFh. Code narrowing unsigned values clamps them first. In our builds at -O2 with -march=x86-64-v2:

Clamping uint32_t to at most 65535 is PMINUD against 65535 and PACKUSDW in Clang 23; GCC 14 adds a PAND between them.
Clamping an int32_t to 0..65535 is PACKUSDW alone in Clang, two vectors per instruction. GCC clamps with PMINSD and PMAXSD, masks with PAND and then packs.
Truncating uint32_t to uint16_t is a PAND with 0000FFFFh and PACKUSDW in GCC, after which the clamp changes nothing. Clang picks the low words with PSHUFB and joins two halves with PUNPCKLQDQ.

Arithmetic on uint16_t that C performs on int, such as a shift by a count in a variable, also ends in PACKUSDW after PMOVZXWD and a doubleword shift. For the SSE2 baseline, without this pack, Clang truncates uint32_t to uint16_t with PSHUFLW, PSHUFHW and PSHUFD, and GCC with five unpacks, PUNPCKLWD and PUNPCKHWD, per eight results.

A memory operand must be aligned to 16 bytes. AMD’s latency spreadsheet for Zen 5 gives PACKUSDW one macro-op with a latency of two cycles, on pipes FP1 and FP2. VPACKUSDW, the VEX and EVEX form, packs each 128-bit lane on its own, as VPACKSSDW shows, and AVX-512’s VPMOVUSDW narrows doublewords read as unsigned.

Forms

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

Instruction	Encoding	Requires
`PACKUSDW xmm, m128` PACKUSDW_XMMdq_MEMdq	`66 0F 38 2B /r`	SSE4.1
`PACKUSDW xmm, xmm` PACKUSDW_XMMdq_XMMdq	`66 0F 38 2B /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.

Pack: the doublewords of both sources are narrowed to words with saturation; those of xmm1 fill the low half, those of xmm2 the high half.

Result words 7 to 0: b3, b2, b1, b0, a3, a2, a1, a0.

Operation

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

src1 = xmm1.read()  # xmm1 as it was
for i in range(8):
    j = i % 4
    if i < 4:
        xmm1.w[i] = usat(src1.sd[j], 16)
    else:
        xmm1.w[i] = usat(src2.sd[j], 16)
# 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
`PACKUSDW 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 PACKUSDW, 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_packus_epi32` `__m128i _mm_packus_epi32(__m128i __V1, __m128i __V2)`	`PACKUSDW 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

Signed input#