SFENCE instruction (SSE)

SFENCE orders stores and nothing else: every store before it becomes globally visible before any store after it. Ordinary stores to write-back memory already become visible in program order, so between them it has nothing to do. It is for the stores that may pass others:

the non-temporal stores MOVNTI, MOVNTDQ, MOVNTPS and MASKMOVDQU, which gather in write-combining buffers and leave them in any order, and stores to memory mapped as write-combining, such as a frame buffer. AMD’s manual asks for an SFENCE on both sides: between an ordinary store and a later non-temporal one, and between a non-temporal store and a later ordinary one (volume 2, Table 7-4);
CLFLUSHOPT and CLWB, which may pass earlier stores to other lines but not an SFENCE;
the direct stores MOVDIRI and MOVDIR64B: Intel’s optimization manual puts an SFENCE before such a doorbell write, so that a device cannot see it before the descriptors it announces (Section 3.12.1).

Loads pass it

Both vendors leave loads unordered with SFENCE, in both directions. A load after it may still complete before an earlier store leaves the store buffer, so SFENCE does not give the store-then-load ordering of Dekker’s algorithm; that takes MFENCE or a locked instruction. Intel’s optimization manual adds that an LFENCE next to an SFENCE does not make an MFENCE, since the two fences are not ordered with each other (Section 9.4.5).

The compilers do not add it

C11’s release fence and release store order only ordinary stores: GCC 14 and Clang 23 at -O2 compile atomic_thread_fence(memory_order_release) to no instruction at all and a release store to a plain MOV. A loop of _mm_stream_si128 that ends by storing a ready flag needs an _mm_sfence() between the two; both compilers then emit SFENCE right before the flag’s MOV.

On AMD and Zen 5

AMD’s manual says SFENCE empties the store buffer and every write-combining buffer, and its Zen 5 guide lists SFENCE and MFENCE among the events that close write combining (Table 9) and SFENCE as microcoded. The processor ignores the low three bits of the ModRM byte: 0F AE F8 to 0F AE FF are all SFENCE, and Zen 5 ran F8, FB and FF alike. The CPUID bit is SSE’s (leaf 1, EDX bit 25); AMD’s manual also accepts its MMX extensions (80000001H, EDX bit 22).

In the optimization guide

What the optimization guide says about SFENCE, 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.

Forms

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

Instruction	Encoding	Requires
`SFENCE` SFENCE	`NP 0F AE /7`	SSE

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 store before it is globally visible before any store after
# it, the write-combining buffers' included; loads may pass it.
# ModRM F8 to FF are all SFENCE (Zen 5 ran F8, FB and FF 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
`SSE` SSE	SSE `CPUID.01H:EDX[25]` SSE	Every x86-64 processor in XED’s model and Zen 3 to Zen 6

More SSE instructions

All 65 SSE instructions

Loads pass it#

The compilers do not add it#

On AMD and Zen 5#