RDPID

RDPID copies the IA32_TSC_AUX MSR into a register: the number that RDTSCP returns in ECX, without the time stamp and without RDTSCP’s wait for earlier instructions. The operating system decides what the MSR holds; Linux writes the CPU number into its low 12 bits and the NUMA node above them, and its vDSO answers getcpu() with RDPID where the processor has it. With -mrdpid, or an -march such as icelake-client, goldmont-plus or znver2, GCC 14 and Clang 23 at -O2 compile _rdpid_u32() & 0xfff to rdpid rax and an AND; x86-64-v4 and skylake lack it.

The answer may be stale at once#

Nothing stops the scheduler from moving the thread right after RDPID, so the number says where the thread was, not where it is. That is enough to pick a per-CPU shard of a counter or an allocator cache, where a wrong guess costs only contention, as long as the shard itself is updated atomically. It is not enough to touch per-CPU data without atomics.

Operand size#

The destination is the full 64-bit register in 64-bit mode and a 32-bit one elsewhere; the MSR’s 32 bits are zero-extended. Operand size prefixes do not change that: on Zen 5, rdpid rdx with a 66 prefix still wrote all of RDX, and on CPU 0, where the probe pins itself, it returned 0. The encoding, F3 0F C7 /7 with a register operand, is RDSEED’s with an F3 prefix.

Who may run it#

CR4.TSD, which can forbid RDTSC and RDTSCP outside ring 0, does not affect RDPID; AMD’s manual names that as its purpose, reading the number where the operating system has disabled RDTSCP for user code. Under Intel’s VMX, RDPID follows RDTSCP’s “enable RDTSCP” control and raises #UD in a guest without it (volume 3).

The manuals disagree on the flags. Intel’s says RDPID changes none, and XED records none; AMD’s text says none too, but its flag table marks CF as modified. AMD’s Zen 5 guide lists RDPID as microcoded. The CPUID bit is leaf 07H, ECX bit 22, the same for both vendors.

In the optimization guide

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

Silvermont to Goldmont Plus

• Instruction set and counters: Silvermont is the first Atom core with SSE4.2 and POPCNT; Goldmont Plus adds RDPID and PTWRITE.

Forms

Latency and throughput

Operation

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

dest.write(tsc_aux)              # TSC_AUX's 32 bits, the OS's; in
                                 # 64-bit mode RDPID r64, zero-extended
# 66 and REX.W change nothing: with 66, Zen 5 still writes the 64-bit
# register. CR4.TSD does not stop it, so that a program can read the
# number where the OS keeps RDTSCP from it

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 RDPID, 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.