VINSERTI32X4

VINSERTI32X4 copies a YMM or ZMM source to the destination with one 128-bit block replaced by 16 bytes from an XMM register or memory, then writes the result under a mask of doublewords. A ZMM register has four such blocks, chosen by bits 1:0 of the immediate; a YMM register two, chosen by bit 0. The other bits are ignored. In YMM registers, unmasked, it does what the AVX2 VINSERTI128 does, and that page covers the common uses: joining two halves and loading from two addresses.

On Zen 5, vinserti32x4 zmm7{k6}, zmm12, xmm7, 5Bh took bits 1:0 of 5Bh, 3, and placed XMM7 in doublewords 12 to 15 of the copy; with 43A4h in K6, only doublewords 2, 5, 7, 8, 9 and 14 of ZMM7 were written. vinserti32x4 ymm0{k4}{z}, ymm31, xmm16, 0F7h used only bit 0, put XMM16 in the high half, and zeroed doublewords 1, 3 and 4, whose bits in K4 (E5h) are clear.

In compiled code#

GCC 14 at -O2 with -march=x86-64-v4 builds a zmm register from four XMM values, _mm512_inserti32x4 three times on top of _mm512_castsi128_si512, with three VINSERTI32X4; Clang 23 joins pairs with VINSERTF128 and the halves with VINSERTF64X4. Clang emits the integer name only under a mask: _mm512_mask_inserti32x4 and _mm256_maskz_inserti32x4 are VINSERTI32X4 in both compilers, while the plain intrinsic becomes VINSERTF32X4 in Clang, the same bits. GCC compiles _mm256_inserti32x4(x, y, 1) to the EVEX VINSERTI32X4 on ymm registers, seven bytes in our builds against six for the VEX VINSERTI128 that would do the same, and loads a 16-byte operand into a register first where Clang folds it into the insert. Repeating one XMM register four times, _mm512_broadcast_i32x4, is a VSHUFI32X4 in GCC and a VSHUFI64X2 in Clang, not an insert.

VINSERTI64X2 is the same with a quadword mask and needs AVX512DQ; VINSERTI32X8 and VINSERTI64X4 insert 256 bits. AMD’s Zen 5 latency spreadsheet gives VINSERTI32X4 one cycle and two per cycle on pipes FP1 and FP2, like the VEX VINSERTI128. Zen 5’s 4 recorded cases cover the register and memory forms at both widths.

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.

x = imm8 & (VL // 128 - 1)  # the 128-bit block replaced
for i in range(VL // 32):
    if k1[i]:
        if i // 4 == x:
            zmm1.d[i] = src3.d[i % 4]
        else:
            zmm1.d[i] = zmm2.d[i]
    elif zeroing:
        zmm1.d[i] = 0
    # else: zmm1.d[i] keeps its value
# 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-E6NF

Attributes

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

All forms

write masking

Intrinsics

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

• VGATHERQPS
• VGETEXPPD
• VGETEXPPH
• VGETEXPPS
• VGETEXPSD
• VGETEXPSH
• VGETEXPSS
• VGETMANTPD
• VGETMANTPH
• VGETMANTPS
• VGETMANTSD
• VGETMANTSH
• VGETMANTSS
• VGF2P8AFFINEINVQB
• VGF2P8AFFINEQB
• VGF2P8MULB
• VINSERTF32X4
• VINSERTF32X8
• VINSERTF64X2
• VINSERTF64X4
• VINSERTI32X8
• VINSERTI64X2
• VINSERTI64X4
• VINSERTPS
• VMAXPD
• VMAXPH
• VMAXPS
• VMAXSD
• VMAXSH
• VMAXSS
• VMINPD
• VMINPH
• VMINPS
• VMINSD
• VMINSH
• VMINSS
• VMOVAPD
• VMOVAPS
• VMOVD
• VMOVDDUP

All 686 AVX10.1 instructions