VMULPH

VMULPH multiplies half-precision values element by element, 32 per zmm register, rounding each product once by MXCSR.RC or, on the 512-bit register form, by {er}. It has opcode 59h in EVEX map 5, that of MULPS, and reports invalid, overflow, underflow, precision and denormal; VADDPH covers the format, the CPUID bits and the encoding, and VMULPS the single-precision form.

Squares overflow early#

The largest finite half is 65504, so any half above about 255.9 has a square that overflows to infinity. Intel’s optimization manual warns that 16-bit integers converted to halves land where squaring, as a correlation does, goes to infinity, and suggests scaling them by 1/256 after the conversion, which keeps both 128^2 and (2/256)^2 in the normal range (Section 18.5.7).

In our builds#

At -O2 with -march=x86-64-v4 -mavx512fp16, GCC 14 and Clang 23 compile c[i] = a[i] * b[i] over global _Float16 arrays to VMULPH, GCC on zmm and Clang on ymm registers; a[i] * 2 becomes vaddph x, x, x, which gives the same result, while a[i] * 0.5f16 stays a VMULPH. A multiply followed by an add contracts into a fused multiply-add, as for singles: GCC fuses even across two statements, giving VFMADD132PH, and Clang only within one expression, giving VFMADD213PH, with VMULPH and VADDPH for the two-statement form.

Without AVX512-FP16, as with -march=znver5, both widen the halves with VCVTPH2PS, multiply singles and narrow the product with VCVTPS2PH under MXCSR’s rounding. That gives VMULPH’s result: the product of two halves has at most 22 significant bits and fits a single exactly, so only the narrowing rounds. AMD’s Zen 5 guide does not list AVX512-FP16, and this site’s recorded cases include none of VMULPH.

In the optimization guide

What the optimization guide says about VMULPH, a line per claim. Each links to the claim in the guide, with its sources and where they differ.

Golden Cove and Raptor Cove

• Vectors, AVX-512 and AMX: AVX-512 FP16 adds and multiplies 32 half-precision values per 512-bit register with a latency of four cycles; division and square root take about 31. sources differ

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 // 16):
    if k1[i]:
        a = zmm2.f16[i]
        b = src3.f16[i]
        zmm1.f16[i] = mul(a, b)
    elif zeroing:
        zmm1.f16[i] = 0
    # else: zmm1.f16[i] keeps its value
# m16bcst: src3.f16[i] is the m16 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 VMULPH, 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

• VMOVHLPS
• VMOVHPD
• VMOVHPS
• VMOVLHPS
• VMOVLPD
• VMOVLPS
• VMOVNTDQ
• VMOVNTDQA
• VMOVNTPD
• VMOVNTPS
• VMOVQ
• VMOVSD
• VMOVSH
• VMOVSHDUP
• VMOVSLDUP
• VMOVSS
• VMOVUPD
• VMOVUPS
• VMOVW
• VMULPD
• VMULPS
• VMULSD
• VMULSH
• VMULSS
• VORPD
• VORPS
• VPABSB
• VPABSD
• VPABSQ
• VPABSW
• VPACKSSDW
• VPACKSSWB
• VPACKUSDW
• VPACKUSWB
• VPADDB
• VPADDD
• VPADDQ
• VPADDSB
• VPADDSW
• VPADDUSB

All 686 AVX10.1 instructions