MFENCE instruction (SSE2)

For ordinary (write-back) memory, x86 already keeps loads in order with loads and stores in order with stores, and never moves a store ahead of an earlier load. The one reordering it allows is a load completing before an earlier store to a different address, while the store still waits in the processor’s store buffer. MFENCE removes that case too: nothing after it is seen by other processors before everything ahead of it is.

That matters where each thread writes one variable and then reads another, as in Dekker’s mutual exclusion or a sequentially consistent store followed by a load: without a fence, both threads can read the old values. By both vendors’ manuals, an MFENCE between the store and the load prevents it, and so does a locked instruction. Compilers take the second: GCC 14 and Clang 23 at -O2 compile a sequentially consistent store to XCHG, and atomic_thread_fence(memory_order_seq_cst) to a lock or of 0 into a stack slot, not to MFENCE.

MFENCE is the tool for weakly ordered memory operations:

non-temporal stores such as MOVNTDQ, and stores to write-combining memory, which may pass other stores; by AMD’s optimization guide for Zen 5, MFENCE, like SFENCE, empties the write-combining buffers;
loads from write-combining memory, such as those of MOVNTDQA;
CLFLUSHOPT, which may pass earlier stores to other cache lines.

Intel’s and AMD’s manuals disagree about what else it does. Intel’s says MFENCE does not serialize the instruction stream: later instructions that do not touch memory may run ahead of it, and its RDTSC entry pairs it with LFENCE (MFENCE; LFENCE) to time code after earlier stores. AMD’s lists MFENCE among its serializing instructions, which retire every earlier instruction before the next one is fetched.

In the optimization guide

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

Memory

Non-temporal stores and fences: Streaming stores need an SFENCE before a flag tells another thread that their data is ready, and an LFENCE with an SFENCE is no MFENCE.

Measuring

Reading the time-stamp counter: RDTSC runs out of order with its neighbours unless LFENCE (or MFENCE and LFENCE) before it and LFENCE after it hold it in place.
Reading the time-stamp counter: RDTSCP waits for the code before it but not for the code after it, which an LFENCE after it holds back.

Bulldozer to Excavator

Loads, stores and caches: MFENCE, SFENCE and serializing instructions hold up the core until all earlier work and memory accesses finish, where a locked instruction does not.

Forms

Every encoding of MFENCE that Intel XED knows, one row per XED instruction form (iform). How to read the notation.

Instruction	Encoding	Requires
`MFENCE` MFENCE	`NP 0F AE /6`	SSE2

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
# every load and store before it is globally visible before any
# load or store after it. ModRM F0 to F7 are all MFENCE (Zen 5 ran
# F0, F3 and F7 so)

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

Operands

None: XED lists no operands for this form.

Flags

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

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 set	CPUID	Processors
`SSE2` SSE2	SSE2 `CPUID.01H:EDX[26]` SSE2	Every x86-64 processor in XED’s model and Zen 3 to Zen 6

More SSE2 instructions

All 124 SSE2 instructions