Optimizing code for AMD Jaguar and Puma

Fetch reads an aligned 32-byte block a cycle into a 16-entry byte buffer, and the decoder looks at two 16-byte windows of it, decoding at most two instructions a cycle. An instruction that becomes one macro-op or two decodes directly; longer ones come from microcode. Agner Fog found no penalty for many prefixes or for prefixes that change the length. [AMD 52128, Sections 2.2, 2.3 and 2.8, pages 10 and 18; Agner Fog, Sections 26.3 and 26.4, page 262]

Unlike some older AMD cores, such as the Bulldozer family, Jaguar decodes a NOP with more than three 66h prefixes at full speed, so padding is best a run of 15-byte NOPs and then a shorter one, as LLVM pads for it. AMD suggests stopping at 11 bytes for code that also runs on those older cores. [AMD 52128, Section 2.7.2.1, pages 16 and 17; LLVM 23.1.2, X86.td, line 1589; Agner Fog, Section 26.3, page 262]

Alignment matters little, but a hot loop that starts on a 32-byte boundary gets a full fetch block in its first cycle, and one that starts on a 64-byte line has its first branches in the faster sparse predictor. The loop buffer of four 32-byte chunks only saves power, which may leave room to boost the clock. [AMD 52128, Sections 2.7.2 and 2.7.2.2, pages 16 and 17; Agner Fog, Section 26.2, page 262]

A sideband stack optimizer in the decoder tracks the stack pointer, so a chain of PUSH and POP instructions does not wait on each update of rSP. Agner Fog counts a push or a pop as one op, and a call as two. [AMD 52128, Section 2.8, page 18; AMD 52128, latency spreadsheet, row 507 (POP) and row 577 (PUSH); Agner Fog, Section 26.4, page 262]

Most instructions, a load-op or a read-modify-write on memory included, make one macro-op; a 256-bit AVX instruction makes two, one for each half. Agner Fog found no fusion of a compare with a branch. [AMD 52128, Section 2.2, Table 1, page 10; Agner Fog, Sections 26.3 and 26.4, page 262]

The first two branches of each 64-byte line go in a sparse BTB of 1,024 entries that costs a predicted taken branch one bubble, and further ones in a dense BTB of 1,024 more, up to two per 8 bytes, which costs two for its first branch in a line and one more for each next. An indirect target, or one the address calculator corrects, adds three. [AMD 52128, Sections 2.7.1.2 and 2.7.1.3, page 14; Agner Fog, Section 3.14, pages 37 and 38]

When a line of code leaves the instruction cache, the marks of its first two branches are kept in spare ECC bits of its L2 copy and come back with it, also to other cores that run the same code. Programs with very large code, especially threads sharing it, gain by keeping to two branches per 64-byte line. [AMD 52128, Section 2.7.1.5, page 15; Agner Fog, Section 3.14, page 37]

A conditional branch takes no BTB entry until it is first taken: until then it is predicted not taken, then always taken, and once it has gone both ways the predictor indexed by 26 bits of global history takes over. Agner Fog found no loop predictor, so loops inside loops predict poorly. [AMD 52128, Section 2.7.1.8, page 16; Agner Fog, Section 3.14, page 38]

An indirect branch that has jumped to several targets is predicted by a 512-entry array with the same global history; one with a single target is left to the out-of-page array, which holds the upper bits of 32 targets outside the current 4 KB page. A direct branch from the dense BTB to another page is corrected later at a cost of four cycles. [AMD 52128, Sections 2.7.1.4 and 2.7.1.7, pages 15 and 16; Agner Fog, Section 3.14, page 38]

The return address stack has 16 entries. Unlike Family 10h, the core gives a call to the very next instruction no special care, so 32-bit code that reads EIP with a call and a pop puts the stack out of step; AMD suggests a real subroutine that copies its return address and returns. A plain one-byte ret costs no more than the rep ret once advised. [AMD 52128, Section 2.7.1.6, page 15; Agner Fog, Section 3.14, page 38]

A 16-entry queue tracks fetched code until it retires: one entry for a line with up to two branches and one more for each further branch in it, so code dense in branches can fill it and stall fetch. [AMD 52128, Sections 2.7.1.9 and 2.8, pages 16 and 18]

An lea with one or two inputs is a one-cycle ALU op; with base, index and displacement it runs in the store address unit in 2 cycles. AMD’s spreadsheet and LLVM’s model also count a scaled index as slow, and LLVM gives a 16-bit lea 3 cycles. [AMD 52128, Section 2.9.2, page 19; AMD 52128, latency spreadsheet, row 280 and row 281 (LEA); LLVM 23.1.2, X86ScheduleBtVer2.td, line 942]

The pipelined multiplier takes 3 cycles for operands of up to 32 bits, one a cycle, and 6 for 64-bit ones, one every 4; a form that writes two registers, such as MUL, adds a cycle to both. [AMD 52128, Section 2.9.2, page 19; AMD 52128, latency spreadsheet, Overview sheet, row 20 to row 24]

The radix-4 divider produces two quotient bits a cycle: AMD’s spreadsheet gives DIV and IDIV at most 25 cycles with 32-bit operands and 41 with 64-bit ones, ending early when the quotient is small. Agner Fog found division much faster than on Bobcat. [AMD 52128, Section 2.9.2, page 19; AMD 52128, latency spreadsheet, row 128 and row 129 (DIV), row 245 and row 246 (IDIV); Agner Fog, Section 26.5, page 262]

LZCNT and POPCNT take one cycle on either ALU and TZCNT two, while BSF and BSR are microcoded, of seven and eight macro-ops and 4 and 5 cycles, so the newer instructions are the better choice where the zero case allows. LLVM’s model agrees. [AMD 52128, latency spreadsheet, row 45 (BSF), row 46 (BSR), row 306 (LZCNT), row 509 (POPCNT) and row 659 (TZCNT); LLVM 23.1.2, X86ScheduleBtVer2.td, line 245; LLVM 23.1.2, X86ScheduleBtVer2.td, line 249]

SHLD and SHRD are microcoded, six to eight macro-ops in AMD’s spreadsheet, and LLVM treats double shifts as slow on these cores. [AMD 52128, latency spreadsheet, row 622 (SHLD) and row 624 (SHRD); LLVM 23.1.2, X86ScheduleBtVer2.td, line 266; LLVM 23.1.2, X86.td, line 1596]

Agner Fog found that the core keeps the parts of a register narrower than 128 bits together, so a write to AL or AX waits for the last write of the whole register, while the two 128-bit halves of a YMM register are renamed apart. LLVM’s model follows him. [Agner Fog, Section 26.10, page 264; LLVM 23.1.2, X86ScheduleBtVer2.td, line 50]

xor, sub and cmp of a register with itself, and pxor, pandn, psub*, pcmpeq*, pcmpgt*, xorps and xorpd likewise, do not wait for the old value, and sbb waits only for the carry; ANDNPS and ANDNPD join them on Jaguar. A register move is eliminated only when its source is such a zeroed vector register, as in a chain of MOVDQA from it. [Agner Fog, Section 26.8, page 263; LLVM 23.1.2, X86ScheduleBtVer2.td, line 63; LLVM 23.1.2, X86ScheduleBtVer2.td, line 873]

LLVM’s model gives a locked read-modify-write such as lock inc 19 cycles, a locked cmpxchg 17 and an xchg with memory, which locks by itself, 16; AMD’s spreadsheet lists XCHG and MFENCE as microcoded. [LLVM 23.1.2, X86ScheduleBtVer2.td, line 395; LLVM 23.1.2, X86ScheduleBtVer2.td, line 326; LLVM 23.1.2, X86ScheduleBtVer2.td, line 476; AMD 52128, latency spreadsheet, row 313 (MFENCE) and row 1166 (XCHG)]

Vector integer ALU ops and floating-point logic take one cycle on either pipe, a vector integer multiply 2 on pipe 0, a floating-point addition 3 on pipe 0, a single-precision multiply 2 and a double-precision one 4, one every two cycles, on pipe 1, since the two 76-by-27-bit multipliers iterate for doubles. LLVM’s model takes the same for additions and multiplications. [AMD 52128, Section 2.10, Table 2, pages 20 and 21; LLVM 23.1.2, X86ScheduleBtVer2.td, line 532; LLVM 23.1.2, X86ScheduleBtVer2.td, line 554]

Every unit is 128 bits wide, so a 256-bit instruction is two macro-ops and does no more work a cycle than two 128-bit ones, and aligning 256-bit data to 32 bytes gains nothing over 16. GCC vectorizes with 128-bit vectors for Jaguar and splits 256-bit operations. [AMD 52128, Sections 2.5.2 and 2.10, pages 12 and 19; Agner Fog, Sections 26.4 and 26.13, pages 262 and 265; GCC 14.2, config/i386/x86-tune.def, line 550; GCC 14.2, config/i386/x86-tune.def, line 555]

The FPU forms three forwarding domains, floating point (FPA and FPM), vector integer (the VALUs and VIMUL) and store and convert, and a result passed from one to another costs a cycle more. Some instructions, among them PALIGNR, HADDPS, PCLMULQDQ and AESENC, pay that cycle even within their domain. [AMD 52128, Section 2.10, page 21; AMD 52128, latency spreadsheet, row 16 (AESENC), row 240 (HADDPS), row 417 (PALIGNR) and row 431 (PCLMULQDQ); Agner Fog, Section 26.9, page 263]

Agner Fog measured a 40-cycle delay when a floating-point result of one precision feeds an operation of the other, a double sum into a single-precision addition for example. [Agner Fog, Section 26.9, pages 263 and 264]

Division and square root iterate in the multiply unit of pipe 1, not pipelined and without early exit: DIVSS takes 14 cycles, DIVPS, DIVPD and DIVSD 19, SQRTSS 16, SQRTPS 21 and SQRTPD 27, and a 256-bit form twice as long. [AMD 52128, Section 2.10, Table 2, page 21; AMD 52128, latency spreadsheet, row 131 to row 134 (DIVPD to DIVSS), row 632 to row 635 (SQRTPD to SQRTSS), row 740 and row 742 (VDIVPD and VDIVPS); Agner Fog, Section 26.6, page 263]

A move from a general register to an XMM register, as MOVD or an operand of CVTSI2SD or PINSRD, goes through a private scratch location in memory: a store and a load that add 6 cycles. GCC makes no direct moves to vector registers for these cores; the way back costs one extra cycle. [AMD 52128, Appendix A.2, pages 25 and 26; AMD 52128, latency spreadsheet, row 112 (CVTSI2SD), row 327 and row 328 (MOVD) and row 464 (PINSRD); GCC 14.2, config/i386/x86-tune.def, line 443]

Scalar instructions such as SQRTSS and CVTSI2SD keep the rest of their destination and so wait for its last write, unless the core knows that part to be zero: it follows registers whose upper bits an instruction cleared until something nonzero lands there. AMD names 15 instructions that profit, among them the scalar conversions, square roots, roundings and register MOVSS and MOVSD. [AMD 52128, Section 2.11, pages 22 and 23]

A denormal costs over 100 cycles, as an input to a computation unless it came through a load-op, or as a result when underflow and precision exceptions are masked; setting both DAZ and FTZ in MXCSR avoids either, and x87 code has no such escape. Agner Fog measured 40 cycles for an addition with a denormal input and 170 to 210 for a multiplication that underflows. [AMD 52128, Section 2.10.1, pages 21 and 22; Agner Fog, Section 26.6, page 263]

With a YMM register’s halves renamed apart, Agner Fog found no penalty for mixing SSE and AVX code, and LLVM’s tuning for Jaguar, unlike that for the Bulldozer family, inserts no VZEROUPPER. The instruction is microcoded, 46 cycles in LLVM’s model. [Agner Fog, Sections 26.6 and 26.10, pages 263 and 264; LLVM 23.1.2, X86.td, line 1586; LLVM 23.1.2, X86.td, line 1625; LLVM 23.1.2, X86ScheduleBtVer2.td, line 827; AMD 52128, latency spreadsheet, row 1159 (VZEROUPPER)]

AMD’s spreadsheet gives a VMASKMOVPS load the 6 cycles of a load-op, one per 128 bits, and lists MASKMOVDQU as microcoded; LLVM’s model gives MASKMOVDQU 34 cycles and 63 micro-ops. [AMD 52128, latency spreadsheet, row 307 (MASKMOVDQU), row 851 and row 852 (VMASKMOVPS); LLVM 23.1.2, X86ScheduleBtVer2.td, line 837]

An access that crosses a 16-byte boundary takes two cycles of the cache and at least one more of latency, at half the throughput; otherwise movups is as fast as movaps. [AMD 52128, Section 2.5.2, page 12; AMD 52128, latency spreadsheet, Overview sheet, row 15]

A store hands its data to a later load only when both start at the same byte, the store is at least as wide and neither is misaligned. A load whose address matches a store’s in bits 15:4 but not above is delayed. Agner Fog measured 3 cycles from a 32-bit or 64-bit store to its load, 8 for narrower ones and 7 for vectors, and a failed forward costs 4 to 11. [AMD 52128, Section 2.12, page 23; Agner Fog, Section 26.12, Table 26.2, page 264]

A 16-entry queue orders loads and stores and a 20-entry queue holds stores until they are written; loads may pass older loads and stores to other addresses, and up to eight cache misses can be outstanding. [AMD 52128, Section 2.12, page 23]

Each core’s path to the shared L2 carries 16 bytes a cycle, the line’s critical part first, and the four banks let all four cores reach that rate at once, as a private L2 would. [AMD 52128, Section 2.5.3, page 12; Agner Fog, Section 26.11, page 264]

A 1 GB page is held in the TLBs as 2 MB pieces, and once any such piece exists, INVLPG flushes the whole TLB, so AMD suggests that system software avoid 1 GB pages; a 16-entry cache of page directory entries speeds up walks. [AMD 52128, Chapter 1 and Section 2.6.3, pages 7 and 13]

Hardware prefetchers fill the L1 instruction cache, the L1 data cache and the L2, and GCC turns on software prefetching at -O3 for these cores, though AMD’s spreadsheet gives PREFETCHT0 and its kin no timing. [AMD 52128, Sections 2.1 and 2.5.2, pages 9 and 12; AMD 52128, latency spreadsheet, row 516 to row 519 (PREFETCHNTA to PREFETCHT2); GCC 14.2, config/i386/x86-tune.def, line 237]

No pinned AMD guide covers Bobcat, Family 14h; Agner Fog describes it with Jaguar: 64-bit execution units that split each 128-bit instruction into two ops at half the throughput, 64-bit load and store paths, no AVX, a 512 KB L2 for each of its two cores and a 56-entry reorder buffer. AMD gives Jaguar twice the peak throughput of Family 14h for SSE floating-point vectors. [Agner Fog, Sections 26.1, 26.4, 26.5 and 26.11, pages 262 and 264; AMD 52128, Section 2.10, pages 19 and 20; GCC 14.2, common/config/i386/cpuinfo.h, line 173]

Agner Fog found on Bobcat integer division done in the floating-point divider and slower than it, a slow PALIGNR, store forwarding of 8 cycles or more, 150 to 200 cycles for denormals, a 12-entry return stack, and ANDNPS and ANDNPD not taken as zero idioms. [Agner Fog, Section 3.14, page 38; Agner Fog, Sections 26.5, 26.6, 26.8, 26.12 and 26.13, pages 262 to 265]

LLVM has no scheduling model for Bobcat, only its features and tuning, which add VZEROUPPER insertion and drop Jaguar’s AVX, BMI and MOVBE; GCC applies Jaguar’s 128-bit vector tuning to Jaguar alone. [LLVM 23.1.2, X86.td, line 1553; LLVM 23.1.2, X86.td, line 2195; GCC 14.2, config/i386/x86-tune.def, line 555]

No pinned source describes what Puma changed: AMD’s only guide for the family never mentions it, Agner Fog does not name it, and GCC treats every Family 16h processor as Jaguar. [AMD 52128, Revision History, page 6; GCC 14.2, common/config/i386/cpuinfo.h, line 246]