VPMOVUSDW

VPMOVUSDW narrows unsigned doublewords to words, clamping each to 65535: 16 from a ZMM register, 8 from a YMM register or 4 from an XMM register, into a YMM or XMM register or straight to memory. It is the word form of VPMOVUSDB, whose page explains why an unsigned source turns a negative int32_t into the maximum rather than 0; VPMOVDW covers the masked store and the zeroed upper part of the register form, and VPMOVSDW saturates signed values. It is part of AVX-512F.

Recorded on Zen 5#

• Unsigned limits. {evex} vpmovusdw xmmword ptr [mem], ymm17 turned 00008000h and 00008001h into 8000h and 8001h, which a signed saturation would have clamped to 7FFFh, and FFFFFFFFh and FFFF8000h into FFFFh.
• Negative is large. vpmovusdw xmm5, xmm5 turned 80000000h and 7FFFFFFFh into FFFFh, kept 0055h and cleared XMM5 above bit 63.
• The mask decides. A quadword store whose four mask bits in K1 were clear wrote nothing, and vpmovusdw xmm9{k1}{z}, ymm9 wrote only words 5 and 7.

In compiled code#

For d[i] = x > 65535 ? 65535 : x over uint32_t and uint16_t arrays, Clang 23 at -O2 with -march=x86-64-v4 stores 8 words at a time with vpmovusdw xmmword ptr [...], ymm0, also in a loop of unknown length. For signed input clamped to 0 to 65535 it raises the negative values to 0 first with VPMAXSD against a zero register, as on VPMOVUSDB’s page. GCC 14 clamps with VPMINUD against 65535, or VPMAXSD and VPMINSD for the signed input, and joins two ZMM registers with VPERMT2W; it handles the loop of unknown length one element at a time. Both compile _mm512_cvtusepi32_epi16 to vpmovusdw ymm0, zmm0. The SSE4.1 PACKUSDW reads its sources as signed and clamps a negative value to 0.

AMD’s Zen 5 latency spreadsheet gives the register forms one macro-op on pipe FP1 or FP2, with 2 cycles from an XMM source and 4 from a YMM or ZMM one, and the memory forms two macro-ops, 5 cycles from a YMM or ZMM register, as VPMOVDW.

Forms

Latency and throughput

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.

Operation

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

for i in range(VL // 32):
    if k1[i]:
        ymm1.w[i] = usat(zmm2.d[i], 16)
    elif zeroing:
        ymm1.w[i] = 0
    # else: ymm1.w[i] keeps its value
for i in range(VL // 32, 8):
    ymm1.w[i] = 0
# ymm1 is zeroed from bit 128 (xmm) or 256 (ymm) up

for i in range(VL // 32):
    if k1[i]:
        mem.w[i] = usat(zmm2.d[i], 16)
    # else: mem.w[i] is not written

Operands

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.

Register forms

AVX512-E6NF

Memory forms

AVX512-E6

Attributes

What else XED records about the forms. How to read.

All forms

write masking

Memory forms

memory fault suppression

Intrinsics

The C intrinsics of Clang 23.1.2 that compile to VPMOVUSDW, 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.

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.

More AVX10.1 instructions

• VPMOVM2D
• VPMOVM2Q
• VPMOVM2W
• VPMOVQ2M
• VPMOVQB
• VPMOVQD
• VPMOVQW
• VPMOVSDB
• VPMOVSDW
• VPMOVSQB
• VPMOVSQD
• VPMOVSQW
• VPMOVSWB
• VPMOVSXBD
• VPMOVSXBQ
• VPMOVSXBW
• VPMOVSXDQ
• VPMOVSXWD
• VPMOVSXWQ
• VPMOVUSDB
• VPMOVUSQB
• VPMOVUSQD
• VPMOVUSQW
• VPMOVUSWB
• VPMOVW2M
• VPMOVWB
• VPMOVZXBD
• VPMOVZXBQ
• VPMOVZXBW
• VPMOVZXDQ
• VPMOVZXWD
• VPMOVZXWQ
• VPMULDQ
• VPMULHRSW
• VPMULHUW
• VPMULHW
• VPMULLD
• VPMULLQ
• VPMULLW
• VPMULTISHIFTQB

All 686 AVX10.1 instructions