Extensions
Forms
10 (4 VEX, 6 EVEX)
Data
Intel XED v2026.08.23

VAESENC runs one middle round of AES on every 128-bit lane of its second operand and XORs in the round key from the same lane of the third. The round itself is AESENC’s, whose page covers the cipher, the byte order and the use of the last round, VAESENCLAST. What changes is the form:

  • VEX.128 (AES and AVX): one block, like AESENC, but with a separate destination, so the state survives, bits 128 and up of the register cleared, and a memory operand that need not be aligned. GCC 14 and Clang 23 emit it for the same _mm_aesenc_si128 once AVX is on.
  • VEX.256 (VAES): two blocks.
  • EVEX (VAES with AVX512F, plus AVX512VL below 512 bits, or with AVX10.1): xmm, ymm and zmm, up to four blocks, and registers 16 to 31. There is no masking and no embedded broadcast.

XED, whose data the requirements table shows, also asks the EVEX forms for the AES bit next to AVX512F; Intel’s SDM (revision 093) does not.

One key per lane

Each lane takes its own round key, so encrypting four blocks with one key needs the key copied to all four lanes first. Intel’s optimization manual loads each round key with VBROADCASTI64X2 and runs eight blocks in two zmm registers, and reports up to 3.3 times the speed of AESENC (Section 19.1, Example 19-1). For _mm512_aesenc_epi128(s, _mm512_broadcast_i32x4(k)), GCC 14 and Clang 23 at -O2 with -march=znver5 load the key with VBROADCASTI32X4. The same manual names multi-buffer code as the other use: four unrelated streams, each with its own key schedule, in the four lanes.

Zen 5’s 22 recorded cases cover every form, the zmm ones with a different key in each lane, and agree with the page’s pseudocode.

Width on Zen 5

AMD’s Zen 5 guide lists VAESENC with the same figures for every width: one macro-op, a latency of 4 cycles and two per cycle. A zmm VAESENC therefore does four blocks’ work for the cost of one xmm round, as long as there are enough independent blocks to keep it busy: AESENC’s page explains why CBC encryption cannot supply them. The 512-bit intrinsics need -mvaes with AVX-512 (for example -march=znver4, znver5 or icelake-server); -march=znver3 has VAES only for ymm registers.

In the optimization guide

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

Ice Lake to Rocket Lake

  • Vectors and AVX-512: AES rounds run on ports 0 and 1, so existing AES-NI code can reach twice its old peak rate. sources differ

Forms

Every encoding of VAESENC that Intel XED knows, one row per XED instruction form (iform). How to read the notation.
InstructionEncodingRequires
VAESENC xmm, xmm, xmm VAESENC_XMMdq_XMMdq_XMMdqVEX.128.66.0F38.WIG DC /rAES + AVX
VAESENC xmm, xmm, m128 VAESENC_XMMdq_XMMdq_MEMdqVEX.128.66.0F38.WIG DC /rAES + AVX
VAESENC ymm, ymm, ymm VAESENC_YMMu128_YMMu128_YMMu128VEX.256.66.0F38.WIG DC /rVAES
VAESENC ymm, ymm, m256 VAESENC_YMMu128_YMMu128_MEMu128VEX.256.66.0F38.WIG DC /rVAES
VAESENC xmm, xmm, xmm VAESENC_XMMu128_XMMu128_XMMu128_AVX512EVEX.128.66.0F38.WIG DC /rAVX10.1 + VAES or VAES + AES + AVX512F + AVX512VL
VAESENC xmm, xmm, m128 VAESENC_XMMu128_XMMu128_MEMu128_AVX512EVEX.128.66.0F38.WIG DC /rAVX10.1 + VAES or VAES + AES + AVX512F + AVX512VL
VAESENC ymm, ymm, ymm VAESENC_YMMu128_YMMu128_YMMu128_AVX512EVEX.256.66.0F38.WIG DC /rAVX10.1 + VAES or VAES + AES + AVX512F + AVX512VL
VAESENC ymm, ymm, m256 VAESENC_YMMu128_YMMu128_MEMu128_AVX512EVEX.256.66.0F38.WIG DC /rAVX10.1 + VAES or VAES + AES + AVX512F + AVX512VL
VAESENC zmm, zmm, zmm VAESENC_ZMMu128_ZMMu128_ZMMu128_AVX512EVEX.512.66.0F38.WIG DC /rAVX10.1 + VAES or VAES + AES + AVX512F
VAESENC zmm, zmm, m512 VAESENC_ZMMu128_ZMMu128_MEMu128_AVX512EVEX.512.66.0F38.WIG DC /rAVX10.1 + VAES or VAES + AES + AVX512F

Latency and throughput

What the scheduling models of LLVM 23.1.2 give for each form, not measurements: latency / reciprocal throughput in cycles, the ports under them. A row is a model, or models that agree; a dash, a form that its processors lack. Memory forms: latency from the address, ports without the load and store units. Which processors each model covers.
Modelxmm, xmm, xmm
ymm, ymm, ymm
xmm, xmm, m128
ymm, ymm, m256
zmm, zmm, zmmzmm, zmm, m512
Sandy Bridge7 / 1p01513 / 1p015
Haswell7 / 1p513 / 1p5
Broadwell7 / 1p512 / 1p5
Skylake, Skylake-SP4 / 1p010 / 1p0
Ice Lake4 / 1p010 / 1p04 / 1p010 / 1p0
Alder Lake5 / 0.5p0112 / 0.5p01
Sapphire Rapids5 / 0.5p0112 / 0.5p015 / 1p012 / 1p0
Lunar Lake3 / 2V0 V111 / 2.33V0 V1
Piledriver9 / 1FPMMA FPU014 / 1.5FPMMA FPU0
Zen, Zen 24 / 0.5FPU0 FPU111 / 0.5FPU0 FPU1
Zen 34 / 0.5FP0 FP111 / 0.5FP0 FP1
Zen 44 / 0.5FP0 FP111 / 0.5FP0 FP14 / 0.5FP0 FP111 / 0.5FP0 FP1
Jaguar3 / 1FPU0 FPU1 VALU0 VALU1 VIMUL8 / 1FPU0 FPU1 VALU0 VALU1 VIMUL

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.

Element-wise: each 128-bit block of the result comes from the 128-bit block in the same place in each source.
VAESENC: element by elementResult 128-bit block i comes from 128-bit block i of xmm2 and xmm3. Result 128-bit blocks: r0.0xmm2ar0xmm10xmm3or m128b

Every 128-bit block works alike: 1, 2 and 4 128-bit blocks in the xmm, ymm and zmm forms.

Result 128-bit block i comes from 128-bit block i of xmm2 and xmm3. Result 128-bit blocks: r0.

Operation

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

# a middle round of the cipher, in each 128-bit lane
for i in range(VL // 128):
    s = sub_bytes(zmm2.dq[i])    # zmm2: the state
    s = shift_rows(s)
    s = mix_columns(s)
    zmm1.dq[i] = s ^ src3.dq[i]  # AddRoundKey, the lane's key
# zmm1 is zeroed from bit VL up

Run on AMD Zen 5 (EPYC 9645): 22 cases.

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.
OperandKindAction
VAESENC xmm, xmm, xmm/m128 VAESENC ymm, ymm, ymm/m256 VAESENC zmm, zmm, zmm/m512
xmm, ymm, zmmexplicitwrite
xmm, ymm, zmmexplicitread
xmm/m128, ymm/m256, zmm/m512explicitread

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.

VEX forms
avx-type-4
EVEX forms
AVX512-E4

Intrinsics

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

IntrinsicCompiles to
_mm_aesenc_si128 __m128i _mm_aesenc_si128(__m128i __V, __m128i __R)

VAESENC xmm, xmm, xmm VEX.128 -maes -mavxwith AVX enabled

_mm256_aesenc_epi128 __m256i _mm256_aesenc_epi128(__m256i __A, __m256i __B)

VAESENC ymm, ymm, ymm VEX.256 -mvaes

VAESENC ymm, ymm, ymm VEX.256 -mvaes -mavxwith AVX enabled

_mm512_aesenc_epi128 __m512i _mm512_aesenc_epi128(__m512i __A, __m512i __B)

VAESENC zmm, zmm, zmm EVEX.512 -mavx512f -mvaes

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 setCPUIDProcessors
AVXAES

AES + AVX
CPUID.01H:ECX[25] AES
CPUID.01H:ECX[28] AVX

Sandy Bridge, Ivy Bridge, Haswell, Broadwell, Skylake, Comet Lake, Cannon Lake, Ice Lake (client), Tiger Lake, Alder Lake, Arrow Lake, Panther Lake, Nova Lake, Skylake-SP, Cascade Lake, Cooper Lake, Ice Lake (server), Sapphire Rapids, Emerald Rapids, Granite Rapids, Diamond Rapids, Sierra Forest, Clearwater Forest, Knights Landing, Knights Mill, Bulldozer, Piledriver, Zen, Zen+, Zen 2, Zen 3, Zen 4, Zen 5, Zen 6
VAES

VAES
CPUID.(EAX=07H,ECX=0):ECX[9] VAES

Ice Lake (client), Tiger Lake, Alder Lake, Arrow Lake, Panther Lake, Nova Lake, Ice Lake (server), Sapphire Rapids, Emerald Rapids, Granite Rapids, Diamond Rapids, Sierra Forest, Clearwater Forest, Zen 3, Zen 4, Zen 5, Zen 6
AVX512_VAES_128

AVX10.1 + VAES
CPUID.(EAX=07H,ECX=0):ECX[9] VAES
CPUID.(EAX=07H,ECX=1):EDX[19] AVX10
CPUID.(EAX=24H,ECX=0):EBX[7:0] ≥ 1 AVX10 version

or

VAES + AES + AVX512F + AVX512VL
CPUID.(EAX=07H,ECX=0):ECX[9] VAES
CPUID.01H:ECX[25] AES
CPUID.(EAX=07H,ECX=0):EBX[16] AVX512F
CPUID.(EAX=07H,ECX=0):EBX[31] AVX512VL

XED and Intel’s SDM differ: XED also asks for the AES bit, CPUID.01H:ECX[25], in the alternative with AVX512F, though not in the one with AVX10.1. Revision 093 of Intel’s SDM does not: its entries for AESDEC, AESDECLAST, AESENC and AESENCLAST give the EVEX forms VAES with AVX512F (AVX512VL for xmm and ymm registers) or VAES with AVX10.1, and name AES only for the legacy and VEX.128 forms.

Sources: Intel XED v2026.08.23, datafiles/gfni-vaes-vpcl/cpuid-evex.xed.txt; Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 2 (325383-093, September 2026), AESDEC, AESDECLAST, AESENC and AESENCLAST: the opcode tables, pages 3-33, 3-39, 3-45 and 3-51.

Ice Lake (client), Tiger Lake, Nova Lake, Ice Lake (server), Sapphire Rapids, Emerald Rapids, Granite Rapids, Diamond Rapids, Zen 4, Zen 5, Zen 6
AVX512_VAES_256
Same as AVX512_VAES_128

XED and Intel’s SDM differ: see the note on AVX512_VAES_128.

Same as AVX512_VAES_128
AVX512_VAES_512

AVX10.1 + VAES
CPUID.(EAX=07H,ECX=0):ECX[9] VAES
CPUID.(EAX=07H,ECX=1):EDX[19] AVX10
CPUID.(EAX=24H,ECX=0):EBX[7:0] ≥ 1 AVX10 version

or

VAES + AES + AVX512F
CPUID.(EAX=07H,ECX=0):ECX[9] VAES
CPUID.01H:ECX[25] AES
CPUID.(EAX=07H,ECX=0):EBX[16] AVX512F

XED and Intel’s SDM differ: see the note on AVX512_VAES_128.

Same as AVX512_VAES_128

More AES-NI instructions

More VAES instructions

More AVX10.1 instructions

All 686 AVX10.1 instructions

Sources

  1. Intel XED v2026.08.23 (commit 0bcb6237345c): forms, encodings, operands, flags, exception classes, attributes, ISA sets, CPUID bits and chip model.
  2. The CPU data of x86-64.net: Zen 3 to Zen 6, from GCC’s -march feature sets and AMD’s Processor Programming References, which the page of each processor cites.
  3. Clang's x86 intrinsic headers, LLVM 23.1.2 (commit 85ac56026243): the intrinsics, their signatures and doc comments, and the Clang of that release, which compiled each of them.
  4. LLVM 23.1.2's x86 scheduling models (commit 85ac56026243): the latency, reciprocal throughput and ports of each form, as llvm-mca reports them.
  5. Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 2 (325383-093, September 2026): Volume 2A, page 3-45 (AESENC)
  6. Intel Advanced Vector Extensions 10.2 Architecture Specification, revision 7.0 (361050-007, April 2026)
  7. Intel 64 and IA-32 Architectures Optimization Reference Manual, Volume 1 (248966-051, October 2026)
  8. Software Optimization Guide for the AMD Zen5 Microarchitecture (58455, rev. 1.00, August 2024), Wayback Machine copy of AMD's ZIP

The tables are derived from Intel XED, Copyright Intel Corporation, licensed under the Apache License 2.0; x86-64.net converted and reformatted them. The intrinsics and their signatures come from Clang and the timings from LLVM's scheduling models, both part of the LLVM Project, licensed under the Apache License 2.0 with LLVM Exceptions. The text is our own.