VCVTQQ2PD

VCVTQQ2PD converts each signed quadword of an XMM, YMM or ZMM register, or of memory, to a double: the vector form of C’s conversion from long to double. It came with AVX512DQ, together with VCVTTPD2QQ, which goes the other way. SSE2 and AVX2 convert packed doublewords to doubles with CVTDQ2PD, but have nothing for quadwords.

Rounding#

A double has a 53-bit significand, so integers up to 2^53 in magnitude convert exactly and larger ones may not: the result is rounded as MXCSR.RC says, or as the instruction’s {er} operand says in the 512-bit register form, and an inexact result sets PE. The cases recorded on Zen 5 show what that means near the ends of the range. 7FFFFFFFFFFFFDFFH, 2^63 minus 513, rounded up became 2^63, and set PE: a value that no quadword holds, so converting it back with VCVTTPD2QQ gives the integer indefinite. Rounded down, the same input became 2^63 minus 1024, the largest double below 2^63. 2^53 plus 1 became 2^53 under rounding toward zero, and -2 became -2.0 exactly.

What the compilers do#

Without AVX512DQ, GCC 14 and Clang 23 at -O2 compile a loop of out[i] = (double)in[i] over long to one CVTSI2SD per element. To avoid the false dependency that the CVTSI2SD page describes, each conversion follows a zeroing of its destination, or, with -mavx2, the VEX form names a register the loop never writes as the source of the upper half: GCC one it zeroed before the loop, Clang XMM15. With -march=x86-64-v4 both use VCVTQQ2PD, GCC on ZMM registers and Clang on YMM registers, with no such dependency: the packed form writes every element.

As an EVEX instruction it writes under a mask, merging or zeroing the elements left out, and can broadcast one quadword from memory to every element. VCVTUQQ2PD converts unsigned quadwords, and VCVTQQ2PS converts to singles, filling half the width of its source. AMD’s Zen 5 guide lists VCVTQQ2PD as one macro-op with a latency of three cycles at every width.

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]:
        zmm1.f64[i] = to_f64(src2.sq[i])
    elif zeroing:
        zmm1.f64[i] = 0
    # else: zmm1.f64[i] keeps its value
# m64bcst: src2.q[i] is the m64 for every i
# {er}: the form's rounding, not MXCSR.RC, and no flags
# zmm1 is zeroed from bit VL up

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.

All forms

AVX512-E2

Attributes

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

All forms

write masking; follows MXCSR

Memory forms

embedded broadcast (tuple Full); memory fault suppression

Intrinsics

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

• VCVTPD2PS
• VCVTPD2QQ
• VCVTPD2UDQ
• VCVTPD2UQQ
• VCVTPH2DQ
• VCVTPH2PD
• VCVTPH2PS
• VCVTPH2PSX
• VCVTPH2QQ
• VCVTPH2UDQ
• VCVTPH2UQQ
• VCVTPH2UW
• VCVTPH2W
• VCVTPS2DQ
• VCVTPS2PD
• VCVTPS2PH
• VCVTPS2PHX
• VCVTPS2QQ
• VCVTPS2UDQ
• VCVTPS2UQQ
• VCVTQQ2PH
• VCVTQQ2PS
• VCVTSD2SH
• VCVTSD2SI
• VCVTSD2SS
• VCVTSD2USI
• VCVTSH2SD
• VCVTSH2SI
• VCVTSH2SS
• VCVTSH2USI
• VCVTSI2SD
• VCVTSI2SH
• VCVTSI2SS
• VCVTSS2SD
• VCVTSS2SH
• VCVTSS2SI
• VCVTSS2USI
• VCVTTPD2DQ
• VCVTTPD2QQ
• VCVTTPD2UDQ

All 686 AVX10.1 instructions