SERIALIZE

SERIALIZE waits until every earlier instruction has finished, with its changes to registers, flags and memory made and the buffered stores written out, and only then fetches the next instruction. It changes nothing itself. Intel’s volume 3 (Section 11.3) calls that a serializing instruction and lists the others: CPUID, IRET and RSM among those a program may run, and privileged ones such as WRMSR and moves to control registers. SERIALIZE is the only one that does nothing else.

Instead of CPUID#

Before it, user code serialized with CPUID, which overwrites EAX, EBX, ECX and EDX and, in a virtual machine, always exits to the hypervisor. Intel’s optimization manual (Section 2.8.1) names both costs and presents SERIALIZE, introduced with Alder Lake and Sapphire Rapids, as the replacement: it writes no register and causes no VM exit. Where CPUID has to serve, the manual recommends leaf 0, the quickest when run natively.

One place that needs serialization is code written by one thread and run by another. Intel’s volume 3 (Section 11.1.3) asks the thread that runs it to wait for a flag that the writer sets after storing the code, then run a serializing instruction before jumping to the new code: the case of a JIT compiler whose code other threads run.

Not a fence#

LFENCE, SFENCE and MFENCE order loads and stores, but Intel’s volume 3 says they do not serialize: later instructions may already have been fetched, and a store before an LFENCE may still be in the store buffer when it completes. SERIALIZE stops both. For ordering RDTSC against the code it times, LFENCE is enough and exists on far more processors.

Availability#

CPUID leaf 7, EDX bit 14, reports it. GCC 14 and Clang 23 at -O2 compile _serialize() to the bare instruction with -mserialize or an -march such as alderlake, sapphirerapids or sierraforest, and reject it for x86-64-v4, znver4 and znver5. AMD’s manual does not describe SERIALIZE, and the Zen 5 guest that ran the probe does not report it, so this page has no recorded cases; a program checks the bit and falls back to CPUID where it is clear.

In the optimization guide

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

Measuring

• Reading the time-stamp counter: CPUID serializes but is slow and exits to the hypervisor in a VM; Intel prefers SERIALIZE where it exists.

Forms

Operation

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

pass                             # no register, flag or memory changes
# the next instruction is fetched only once every earlier one has
# completed and its stores are written, as after CPUID, which
# serializes too but writes four registers

Operands

None: XED lists no operands for this form.

Flags

None: XED records no flag that the forms test or change.

Intrinsics

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