MOVMSKPD instruction (SSE2)

MOVMSKPD copies the sign bits of the two quadwords of an XMM register into bits 1:0 of a general-purpose register and clears the rest of it. It is the double-precision form of MOVMSKPS, whose page covers what the sign bits mean: a set bit after a compare is a true element, while on raw data it is C’s signbit, set for -0.0 and for NaNs with the sign bit set. The recorded Zen 5 case shows both points: movmskpd eax, xmm1, with the quiet NaN FFF8000000000005h in the low double and the signaling NaN 7FF0000000012345h in the high one, wrote 1 and cleared the upper half of RAX as well, where BF244D076BA07303h had been. Nothing is converted, so no NaN raises a flag.

In compiled code

In our builds at -O2 for the x86-64 baseline, GCC 14 and Clang 23 use it for C’s signbit on a double: movmskpd eax, xmm0 and an AND with 1. Over the result of a compare, _mm_movemask_pd(_mm_cmplt_pd(a, b)) is CMPLTPD and MOVMSKPD in both; for “all”, GCC compares the mask with 3, while Clang inverts the compare to CMPNLTPD and tests for zero, as it does with four singles.

Since the instruction looks only at bit 63 of each element, it also collects the signs of two 64-bit integers: _mm_movemask_pd(_mm_castsi128_pd(v)) compiles to MOVMSKPD alone. SSE2 has no 64-bit form of PMOVMSKB, so this is the usual way to test two int64_t compares, such as those of PCMPGTQ, for “any” or “all”.

AMD’s latency spreadsheet for Zen 5 lists MOVMSKPD as one macro-op on pipes FP4 and FP5. VMOVMSKPD, the VEX form, gives 4 bits from a YMM register; AVX-512 compares write mask registers instead, and VPMOVQ2M collects the sign bits of quadwords into one.

Forms

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

Instruction	Encoding	Requires
`MOVMSKPD r32, xmm` MOVMSKPD_GPR32_XMMpd	`66 0F 50 /r`	SSE2

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.

To a mask: each double of the source sets one bit of r32, bit i for double i; the bits above them are cleared.

Bit i of r32 comes from double i of xmm2. Result bits 1 to 0: r1, r0.

Operation

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

r = 0
for i in range(2):
    r |= (xmm2.sq[i] < 0) << i
dest.write(r)  # the other bits are cleared

Run on AMD Zen 5 (EPYC 9645): 1 case.

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
`MOVMSKPD r32, xmm`
`r32`	explicit	write
`xmm`	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_7

Intrinsics

The C intrinsics of Clang 23.1.2 that compile to MOVMSKPD, 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_movemask_pd` `int _mm_movemask_pd(__m128d __a)`	`MOVMSKPD r32, xmm` Legacy -msse2

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
`SSE2` SSE2	SSE2 `CPUID.01H:EDX[26]` SSE2	Every x86-64 processor in XED’s model and Zen 3 to Zen 6

More SSE2 instructions

All 124 SSE2 instructions

In compiled code#