CLDEMOTE

CLDEMOTE asks the processor to move the cache line holding a byte out of the caches next to the core to a more distant level that other cores share, typically the L3 cache of a server. It is for data that one core writes and others read next. Without it, each reader misses in its own caches and has to fetch the line from the writer’s; after a CLDEMOTE it finds the line in the shared cache. Intel’s optimization manual (Section 17.26) presents it that way and notes that the gain grows with the number of readers.

Only a hint#

CLDEMOTE changes no register, flag or memory, raises no exception for any address (only a LOCK prefix makes it #UD), and the processor may ignore it: a line that is not in the caches, or one in uncacheable memory, stays where it is. Unlike CLFLUSH, CLFLUSHOPT and CLWB, it does not promise to write modified data back to memory, so it is no step towards persistence. Intel’s reference orders it only with stores to the same line, so it belongs after the last store that fills the line, and it advises that the same core not touch the line again soon afterwards, which would pull it back.

Safe without CPUID#

Intel’s reference says that processors without CLDEMOTE, older ones included, run its encoding, 0F 1C /0, as a NOP. So code may issue it without first testing CPUID leaf 7, ECX bit 25, unlike most new instructions. The compilers still ask for the feature: GCC 14 and Clang 23 at -O2 accept _cldemote(p) only with -mcldemote or an -march such as sapphirerapids or sierraforest. A function that fills 64 bytes and then calls it compiles to the stores followed by cldemote [rdi]. GCC’s header declares the parameter as void *, so passing a const pointer draws a warning, while Intel’s reference and Clang declare it const void *.

The Zen 5 guest that ran the probe does not report CLDEMOTE in CPUID, and AMD’s manual does not describe it, so this page has no recorded cases.

In the optimization guide

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

pass                             # a hint: the line may move from the
                                 # caches next to the core to a more
                                 # distant one, which other cores
                                 # reach sooner
# no fault, and no write back; a processor without CLDEMOTE runs
# 0F 1C /0 as a hint NOP

Operands

Flags

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

Intrinsics

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