LFENCE instruction (SSE2)

The name says “load fence”, but on ordinary write-back memory x86 never reorders loads with each other, so as a memory barrier LFENCE matters only for weakly ordered loads, such as those from write-combining memory. It is used for something else: on Intel’s processors no instruction after LFENCE starts, not even speculatively, until every instruction before it has completed locally. That makes it an execution barrier, lighter than a serializing instruction because it does not wait for earlier stores to become visible to other processors.

The two common uses follow from that:

Timing. RDTSC does not wait for anything, so timing code puts an LFENCE before it to make the reading wait for the code being measured, and after it to keep later code from starting early. To also wait for earlier stores, Intel’s RDTSC entry puts an MFENCE in front of the LFENCE.
Speculation barrier. A bounds check followed by LFENCE keeps the processor from running the access past a mispredicted check, and Intel’s manual suggests an LFENCE after an indirect JMP or CALL to stop speculation into the bytes that follow it.

AMD’s manual defines LFENCE only as an ordering of loads. It becomes dispatch serializing, which gives the behaviour above, where the operating system turns that on in a model-specific register, and always on processors that set CPUID Fn8000_0021_EAX bit 2 (LFenceAlwaysSerializing). Without either, AMD’s manual promises only the ordering of loads.

LFENCE does not empty the store buffer, so it does not make earlier stores visible and is no substitute for MFENCE or a locked instruction between a store and a later load. When every earlier instruction and store must be finished, use SERIALIZE or CPUID.

In the optimization guide

What the optimization guide says about LFENCE, 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.
Reading the time-stamp counter: On AMD’s processors LFENCE keeps later instructions waiting only where it is dispatch serializing, which CPUID 8000_0021H EAX bit 2 reports.

Forms

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

Instruction	Encoding	Requires
`LFENCE` LFENCE	`NP 0F AE /5`	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 before it is done before any load after it starts.
# Intel's manual: no later instruction starts until every earlier
# one has completed locally; AMD's: dispatch serializing where
# CPUID Fn8000_0021_EAX[2] says so or the OS sets it so. ModRM E8
# to EF are all LFENCE (Zen 5 ran E8, EB and EF 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