AADD

AADD adds a general-purpose register to a doubleword or quadword in memory atomically, as lock add does, but returns nothing and keeps much weaker ordering: it is one of RAO-INT’s remote atomic operations, which the processor may carry out far from the core, in a shared cache or at the memory controller. The destination must be memory, naturally aligned to its size and of the write-back type; a misaligned or non-WB destination raises #GP. A LOCK prefix raises #UD, and the flags are left alone. AAND, AOR and AXOR are the bitwise forms, on the same opcode, 0F38 FC, told apart by the prefix: none for AADD, then 66, F2 and F3.

Order and fences#

Intel gives these operations the ordering of write-combining stores, like MOVNTI’s. One core’s accesses to the same location stay in program order, but an AADD may pass writes and other remote atomics to other addresses, so a set of them may reach memory in any order. Code that needs more uses SFENCE or MFENCE; an LFENCE after an AADD does not hold it back, as AADD loads nothing into the core. Inside a TSX transaction it aborts the transaction.

Where it pays#

Intel’s example is a histogram shared by many cores: with XADD or lock add, a contended bin’s line moves from core to core for every update, while remote updates meet where the line already is. The same text warns that reading the location soon after, or mixing ordinary accesses with the updates, loses the benefit, and that an implementation may combine updates of one line only when they share the operation or the size, so mixed updates of a line are better kept apart in time.

In our builds and on Zen 5#

GCC 14 and Clang 23 at -O2 with -mraoint compile _aadd_i32(&c, v) to aadd dword ptr [rip + c], edi (GCC’s spelling differs) and a histogram loop over _aadd_i32(&hist[p[i]], 1) to one AADD per byte. Neither picks it for a relaxed __atomic_fetch_add with the result unused, which stays lock add. Neither enables it for -march=sierraforest, grandridge or clearwaterforest, nor Clang 23 for diamondrapids. The Zen 5 behind this site’s recorded cases reports CPUID.(EAX=07H,ECX=1):EAX as 30h, without RAO-INT’s bit 3, and both cases, 32- and 64-bit, raised #UD.

Forms

Operation

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

if not cpuid_leaf(7, 1)[0] >> 3 & 1:
    fault(UD)                    # CPUID: no RAO-INT
dest.write(dest + src)           # one atomic read-modify-write, weakly
                                 # ordered, unlike LOCK ADD: #GP(0) unless
                                 # dest is aligned to its size and in
                                 # write-back memory; no flag changes

Operands

Flags

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

Exceptions

The exception class is XED's name for the set of exception conditions that a form follows. How to read.

Legacy forms

LEGACY-RAO-INT

EVEX forms

APX-EVEX-RAO-INT

Attributes

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

All forms

always atomic; may abort a TSX transaction

AADD m32, r32

4-byte aligned memory operand

AADD m64, r64 64-bit mode only

8-byte aligned memory operand

Intrinsics

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

More RAO-INT instructions

• AAND
• AOR
• AXOR

More APX instructions

• AAND
• ADC
• ADCX
• ADD
• ADOX
• AND
• ANDN
• AOR
• AXOR
• BEXTR
• BLSI
• BLSMSK
• BLSR
• BZHI
• CCMPscc
• CFCMOVcc
• CMOVcc
• CMPccXADD
• CRC32
• CTESTscc
• DEC
• DIV
• ENQCMD
• ENQCMDS
• IDIV
• IMUL
• INC
• INVEPT
• INVPCID
• INVVPID
• JMPABS
• KMOVB
• KMOVD
• KMOVQ
• KMOVW
• LDTILECFG
• LZCNT
• MOVBE
• MOVDIR64B
• MOVDIRI

All 88 APX instructions