PHADDW

PHADDW adds neighboring pairs of words, the destination’s pairs giving the low half of the result and the source’s the high half: eight sums in an XMM register, four in an MMX one, laid out as PHADDD describes for doublewords. Each sum keeps its low 16 bits, which serves signed and unsigned words alike, and no flag reports a carry or an overflow; PHADDSW clamps instead. On Zen 5, the recorded phaddw xmm7, xmm11 turned the pairs 0001h, FFFFh into 0000h and 7FFFh, 8000h into FFFFh in XMM7’s half, and FFFFh, FFFFh into FFFEh in XMM11’s, and kept bits 511:128 of XMM7 (see mixing SSE and AVX). PHSUBW subtracts within each pair.

In compiled code#

In our builds at -O2 over fixed-size int16_t arrays, the sum of adjacent elements, o[i] = a[2*i] + a[2*i+1], is one PHADDW per eight results in Clang 23 with -mssse3, the second vector taken straight from memory, and VPHADDW followed by VPERMQ with -mavx2, since the VEX form adds within each 128-bit lane. GCC 14 never uses it there: with -mssse3 it gathers the even and the odd words with four PSHUFB and two POR and adds them with PADDW; with -march=x86-64-v2 it masks and shifts each doubleword apart and packs the halves with PACKUSDW instead.

When the sum is kept as an int32_t, the pairs must not wrap, so the work moves to doublewords: for the baseline, Clang sign-extends the even words with PSLLD and PSRAD by 16, the odd ones with PSRAD by 16, and adds them with PADDD. Neither compiler uses PHADDW to sum a whole vector of words either: both fold the vector in halves with shifts or shuffles and PADDW.

AMD’s latency spreadsheet for Zen 5 gives PHADDW four macro-ops with a latency of two cycles and one started every two cycles, against one macro-op, one cycle and four per cycle for the vertical PADDW. The XMM form’s memory operand must be aligned to 16 bytes; SSSE3, which added the horizontal adds and subtracts, is part of x86-64-v2.

Forms

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.

src1 = mm1.read()  # mm1 as it was
for i in range(4):
    j = 2 * (i % 2)
    if i < 2:
        mm1.w[i] = src1.w[j] + src1.w[j + 1]
    else:
        mm1.w[i] = src2.w[j] + src2.w[j + 1]
# x87: TOP = 0, all tags valid, bits 79:64 of mm1's register all ones

src1 = xmm1.read()  # xmm1 as it was
for i in range(8):
    j = 2 * (i % 4)
    if i < 4:
        a = src1.w[j]
        b = src1.w[j + 1]
        xmm1.w[i] = a + b
    else:
        a = src2.w[j]
        b = src2.w[j + 1]
        xmm1.w[i] = a + b
# bits 128 and up of the register are unchanged

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.

PHADDW mm, mm/m64

mmx-mem

PHADDW xmm, xmm/m128

SSE_TYPE_4

Attributes

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

PHADDW mm, mm/m64

may abort a TSX transaction

PHADDW xmm, m128

aligned memory operand

Intrinsics

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

• PABSB
• PABSD
• PABSW
• PALIGNR
• PHADDD
• PHADDSW
• PHSUBD
• PHSUBSW
• PHSUBW
• PMADDUBSW
• PMULHRSW
• PSHUFB
• PSIGNB
• PSIGND
• PSIGNW