CLWB

CLWB writes a modified cache line back to memory, as CLFLUSHOPT does, but need not evict it: the line may stay in the caches, now unmodified, so that the next access to it hits. That is a hint, not a promise; Intel’s manual lets the processor drop the line anyway, and AMD’s says only that it may be retained. A line that is not modified is not written. Either way memory ends up holding the data, which is what software for persistent memory needs, and Intel’s optimization manual recommends CLWB over the flushes where the data will be used again (Section 12.4).

How it is used#

The pattern is the one of CLFLUSHOPT: store, CLWB each line written, then SFENCE. Intel’s manual orders CLWB with fences, locked instructions and earlier stores to the same line, and with nothing else: not with other CLWBs, CLFLUSHOPTs or flushes, nor with later stores. AMD’s manual calls it weakly ordered, ordered only with older stores to the same address, and asks for SFENCE or stronger. Without the fence, a store that publishes the data, such as a flag or a log’s tail pointer, may reach memory before the data it covers.

CLWB is checked like a 1-byte read and sets the accessed bit but not the dirty bit. On Zen 5 it ran on a mapped line, and raised #PF for an unmapped address near 0 and for a kernel address, as CLFLUSHOPT did.

Encoding and support#

CLWB is 66 0F AE /6 with a memory operand; without the 66 prefix the same bytes are XSAVEOPT. Its CPUID bit is leaf 7, EBX bit 24, separate from CLFLUSHOPT’s bit 23. GCC 14 and Clang 23 accept _mm_clwb(p) with -mclwb or an -march that has it, such as skylake-avx512 or znver2 and later; -march=skylake, icelake-client and znver1 have CLFLUSHOPT but not CLWB, and there both compilers reject the call. A loop over a buffer in steps of 64 compiles to one CLWB per line, unrolled twice by GCC.

Cost#

AMD’s Zen 5 guide lists CLWB as microcoded, where CLFLUSHOPT is a single macro-op. Whether CLWB saves time therefore depends on the next access finding the line still cached, which neither vendor guarantees.

In the optimization guide

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

Tremont

• Instruction set and Lakefield: Tremont adds UMWAIT, TPAUSE, CLWB, CLDEMOTE and the direct stores, which GCC enables for it. sources differ

Forms

Latency and throughput

Operation

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

a = src.address                  # DS:, or a segment prefix's base
if not canonical(a):
    fault(GP, 0)                 # #SS(0) through RSP or RBP
if not readable(a):
    fault(PF)                    # the checks of a 1-byte read
# a modified line is written back to memory, and may stay in the
# caches, unmodified; memory keeps its value. Ordered as CLFLUSHOPT

Operands

Flags

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

Attributes

What else XED records about the forms. How to read.

All forms

memory operand only names cache lines

Intrinsics

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