VPMOVQD

VPMOVQD narrows each quadword to a doubleword by keeping its low 32 bits: 8 quadwords of a ZMM register become 8 doublewords in a YMM register or in memory, 4 from a YMM register and 2 from an XMM one. It is the C conversion (uint32_t)x or (int32_t)x of a 64-bit integer, and the reverse of VPMOVZXDQ and VPMOVSXDQ. VPMOVDB explains the family of AVX-512 down conversions, the masked narrowing store and the saturating siblings; for quadwords to doublewords these are VPMOVSQD, which clamps to the signed 32-bit range, and VPMOVUSQD, which clamps unsigned values to FFFFFFFFh.

Two vectors into one, or one into half#

The register form leaves a destination half the width of its source and zeroes everything above it. That fits loops that narrow as they store: for d[i] = (uint32_t)a[i] over arrays, Clang 23 at -O2 with -march=x86-64-v4 loads ymm registers and stores each 4 results with vpmovqd xmmword ptr [rdi + 4*rax], ymm0, and for znver5 does the same on zmm registers. GCC 14 takes another route for both targets: it loads two zmm registers and picks their even doublewords with one VPERMT2D, giving a full zmm result; for the high halves, a[i] >> 32, the same VPERMT2D picks the odd doublewords, with no shift at all. With a saturating loop, Clang uses VPMOVSQD, while GCC clamps with VPMAXSQ and VPMINSQ and then permutes.

AVX2 has no such instruction. For x86-64-v3, Clang moves the even doublewords of each ymm register to its low half with VPERMPS, and GCC uses two VPERM2I128 and two VPSHUFD per pair of registers. In both, a signed clamp first needs VPCMPGTQ and a blend for each bound, since AVX2 has no 64-bit minimum or maximum.

Zen 5#

AMD’s Zen 5 guide lists the register forms as one macro-op, with a latency of 2 cycles for xmm and 4 for ymm and zmm, and the memory forms as two macro-ops with a latency of 3 and 5. The cases recorded on Zen 5 agree with the page’s pseudocode: the register form zeroed the destination above the doublewords it wrote, and the masked memory form left the doublewords of masked-off elements in memory alone.

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 // 64):
    if k1[i]:
        ymm1.d[i] = zmm2.q[i]  # the low bits
    elif zeroing:
        ymm1.d[i] = 0
    # else: ymm1.d[i] keeps its value
for i in range(VL // 64, 4):
    ymm1.d[i] = 0
# ymm1 is zeroed from bit 128 (xmm) or 256 (ymm) up

for i in range(VL // 64):
    if k1[i]:
        mem.d[i] = zmm2.q[i]  # the low bits
    # else: mem.d[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 VPMOVQD, 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

• VPMAXUQ
• VPMAXUW
• VPMINSB
• VPMINSD
• VPMINSQ
• VPMINSW
• VPMINUB
• VPMINUD
• VPMINUQ
• VPMINUW
• VPMOVB2M
• VPMOVD2M
• VPMOVDB
• VPMOVDW
• VPMOVM2B
• VPMOVM2D
• VPMOVM2Q
• VPMOVM2W
• VPMOVQ2M
• VPMOVQB
• VPMOVQW
• VPMOVSDB
• VPMOVSDW
• VPMOVSQB
• VPMOVSQD
• VPMOVSQW
• VPMOVSWB
• VPMOVSXBD
• VPMOVSXBQ
• VPMOVSXBW
• VPMOVSXDQ
• VPMOVSXWD
• VPMOVSXWQ
• VPMOVUSDB
• VPMOVUSDW
• VPMOVUSQB
• VPMOVUSQD
• VPMOVUSQW
• VPMOVUSWB
• VPMOVW2M

All 686 AVX10.1 instructions