Optimizing code for Silvermont and Goldmont

Silvermont decodes up to 16 bytes a cycle, but an instruction longer than 8 bytes decodes alone, on the first decoder. From Goldmont on, the decoders take up to 20 bytes a cycle when the first of three instructions starts on a 4-byte boundary, and long instructions no longer decode alone. [Intel 356477, Section 6.8.1.2, Table 6-12, pages 6-31 and 6-32; Agner Fog, Section 15.2, page 183]

The decoders rely on marks of where instructions start, kept with the instruction cache; when code evicts its own marks, by aliasing or by a large footprint, decoding slows to one instruction every three cycles. Goldmont keeps 16 KB of these marks in a second-level cache, Goldmont Plus 64 KB. [Intel 356477, Section 6.5, page 6-21; Intel 356477, Section 6.8.1.1, page 6-31; Intel 356477, Sections 6.6 and 6.7, Tables 6-4 and 6-8, pages 6-25 and 6-28]

Silvermont decodes at full speed only instructions with at most 3 bytes of prefixes and escape bytes together, Goldmont and Goldmont Plus 4. Beyond that an instruction costs 3 cycles and must decode on the first decoder, 6 if it reached another. An SSSE3 or SSE4 instruction already carries 3 (66 and two escape bytes), so naming r8 to r15 or xmm8 to xmm15 makes it slow to decode on Silvermont. [Intel 356477, Section 6.8.1.2, Table 6-12, pages 6-31 and 6-32; Agner Fog, Sections 15.2 and 15.12, pages 183 and 186]

Instructions decoded by the microcode ROM are slow on all four cores, and Silvermont has more of them: push and call with a memory operand, leave, pextrb, pextrd, pextrq, pmulld, and fld and fstp of 80-bit values. Goldmont decodes all of these directly except call with a memory operand, which on every core is better replaced by a load and a call through a register. [Intel 356477, Section 6.8.1.1, Table 6-11, pages 6-30 and 6-31; Intel 356477, Section 6.8.2.8, page 6-36]

On Silvermont nearly every instruction of more than one micro-op comes from the microcode ROM and takes at least 4 cycles to decode, 6 when it first reaches the second decoder. On Goldmont that holds for three micro-ops or more and for some instructions of two. [Agner Fog, Sections 15.2 and 16.2, pages 183 and 188]

Silvermont decodes one branch a cycle: a branch right after another on the second decoder costs 3 cycles. Goldmont decodes two, but two predicted not-taken branches on the first two decoders still cost 3 cycles. The target of a taken branch decodes a cycle late on every Atom core. [Intel 356477, Section 6.8.1.2, Table 6-12, pages 6-31 and 6-32; Agner Fog, Section 15.2, page 183]

A loop stream detector feeds decoded micro-ops of small loops to the back end, and while it runs the limits on length and prefixes do not apply. It holds loops of up to 28 instructions on Silvermont and 27 on Goldmont, so loop unrolling should stay below that. [Intel 356477, Section 6.8.1.4, page 6-33]

None of these cores fuses two instructions into one micro-op, not even a compare and the conditional jump after it. [Agner Fog, Sections 15.4 and 16.5, pages 184 and 189]

Goldmont and Goldmont Plus retire a NOP without sending it to a reservation station, so padding costs only retirement slots. LLVM pads code for Silvermont with NOPs of at most 7 bytes, which its decoders handle quickly, and for Goldmont with its default of 10. [Intel 356477, Section 6.8.2.6, page 6-35; LLVM 23.1.2, X86.td, line 741; LLVM 23.1.2, X86.td, line 1345; LLVM 23.1.2, MCTargetDesc/X86AsmBackend.cpp, line 957; LLVM 23.1.2, MCTargetDesc/X86AsmBackend.cpp, line 966]

Silvermont and Goldmont predict branches twice, when fetching and again when decoding, where the second guess can override the first; Goldmont also lets fetching run ahead of decoding. Silvermont’s predictor keeps a global history of 12 branches, and Agner Fog found no special handling of loops. [Agner Fog, Section 3.9, page 32; Intel 356477, Section 6.6, Table 6-4, pages 6-23 and 6-25]

Silvermont predicts an indirect jump or call to go where it went last time; Goldmont predicts from patterns of earlier targets. [Agner Fog, Sections 3.9 and 15.12, pages 32 and 186]

The return stack buffer holds 16 entries on Silvermont and Goldmont, twice the in-order Atom’s. [Agner Fog, Section 3.9, page 32]

A taken branch the predictor gets right but whose target is missing from the branch target buffer costs about 7 cycles. A taken jump issues at best one every 2 cycles on Goldmont and one a cycle on Goldmont Plus, and more taken jumps in the same aligned 16-byte block of code slow each of them down, to 5 or 6 cycles. [Agner Fog, Section 3.9, page 32; Agner Fog, Section 16.3, Table 16.1, pages 188 and 189]

In 64-bit code, a branch whose target lies more than 4 GB away is predicted worse, which happens most with code spread over shared libraries. Intel suggests static or LTO builds, or glibc 2.23 or later with LD_PREFER_MAP_32BIT_EXEC=1, which loads libraries into the low 2 GB. [Intel 356477, Section 6.8.1.3, page 6-33]

Silvermont runs only integer instructions out of order: each of the two integer stations picks its oldest ready micro-op, while the two vector stations and the memory station issue strictly in order. A station may still get ahead of the others. [Intel 356477, Section 6.5, pages 6-20 to 6-22; Intel 356477, Section 6.8.2.1, page 6-33]

An instruction that loads and computes is split on all four cores: its memory part goes to the memory station and its computing part to an integer or vector station. [Intel 356477, Section 6.5, page 6-22; Intel 356477, Section 6.6, page 6-25]

Goldmont runs integer, vector and memory micro-ops out of order, with one station per integer port and one shared by the two vector ports and one by the two memory ports, so code scheduled for Silvermont’s in-order stations gains little from it. [Intel 356477, Section 6.6, Table 6-5, page 6-25; Intel 356477, Section 6.8.2.1, page 6-33]

On Silvermont a vector store goes to the same in-order port as multiplications, so in an unrolled loop of multiply, add and store, a store waiting for its add holds up the next, unrelated multiply. Moving the stores to the end of the loop body lets the multiplies overlap; Goldmont’s shared station removes the problem. [Intel 356477, Section 6.8.2.3, Examples 6-7 and 6-8, pages 6-34 and 6-35]

On Silvermont shifts and rotates run on integer port 0, and jumps, multiplication, popcnt, crc32 and bit operations on port 1. Goldmont adds a third ALU on port 2 and runs division on port 1; Goldmont Plus moves jumps to a port of their own. [Intel 356477, Section 6.5, Table 6-3, page 6-22; Intel 356477, Section 6.6, Table 6-6, page 6-26; Intel 356477, Section 6.7, Table 6-10, page 6-29]

Silvermont computes addresses as fast with add as with lea. An lea with an index runs on port 1, and one with an index and a displacement is split into micro-ops on both ports, so lea pays where it keeps a source intact or scales the index, and add is better otherwise. LLVM’s tuning marks some lea forms as slow on all four cores. [Intel 356477, Section 6.5, Table 6-3, page 6-22; Intel 356477, Section 6.8.2.2, page 6-33; LLVM 23.1.2, X86.td, line 574; LLVM 23.1.2, X86.td, line 1341]

On Silvermont, imul with two or three operands takes 3 cycles at 32 bits and 5 at 64, while every one-operand mul or imul, which writes a double-width result, comes from microcode (4 to 7 cycles), as does the two-operand 16-bit form. Goldmont runs the 32- and 64-bit one-operand forms in hardware, in 3 and 5 cycles; the 8- and 16-bit ones stay microcoded. [Intel 356477, Section 6.8.2.4, Table 6-13, page 6-35; LLVM 23.1.2, X86ScheduleSLM.td, line 109; LLVM 23.1.2, X86ScheduleSLM.td, line 112]

Silvermont divides in microcode, slowly and in a time that depends on the values: 25 to 38 cycles for div of up to 32 bits and 38 to 123 for 64 bits, more for idiv. Goldmont has hardware for short divisions, 11 to 41 cycles for all sizes. LLVM’s Silvermont tuning divides a 64-bit value that fits in 32 bits with a 32-bit div. [Intel 356477, Section 6.8.2.15, Tables 6-15 and 6-16, pages 6-39 and 6-40; LLVM 23.1.2, X86.td, line 541; LLVM 23.1.2, X86.td, line 1343]

inc and dec leave the carry flag alone and need an extra micro-op to merge the flags, so a branch that depends directly on one waits a cycle more than after add, sub or cmp. LLVM’s tuning for all four cores prefers add and sub. [Intel 356477, Section 6.8.2.9, page 6-36; Agner Fog, Sections 15.8 and 16.8, pages 185 and 190; LLVM 23.1.2, X86.td, line 586; LLVM 23.1.2, X86.td, line 1342]

Silvermont knows that xor of a 32-bit register with itself, and pxor, xorps or xorpd of an XMM register with itself, does not depend on the old value, but not a 64-bit xor with REX.W, nor sub or narrower forms: clear r8 with xor r8d, r8d, which zeroes all 64 bits. Goldmont accepts the 64-bit form too. [Intel 356477, Section 6.8.2.5, page 6-35; Agner Fog, Sections 15.6 and 16.6, pages 184 and 189]

From Goldmont on, a 32- or 64-bit mov between registers and a movaps, movapd, movdqa, movdqu, movups or movupd between XMM registers can be done by renaming, in no time and three a cycle; movsx and movzx cannot. Silvermont has no move elimination. [Intel 356477, Section 6.8.2.7, pages 6-35 and 6-36]

Goldmont tracks the stack pointer of push, pop, call and ret without spending allocation or execution slots on it, and runs push and pop three a cycle where Silvermont runs one. [Intel 356477, Section 6.8.2.7, page 6-36]

A shift by cl waits an extra cycle when the count comes from the instruction just before it. shld and shrd on 64-bit operands, or with a memory destination or a count in cl, come from microcode on both generations; with a 32-bit register and an immediate count, Silvermont microcodes shrd but not shld, and Goldmont neither. [Intel 356477, Section 6.8.2.16, page 6-40]

popcnt takes 3 cycles, one a cycle, on Silvermont and Goldmont. LLVM’s tuning for both makes it wait for its destination register’s old value, which its Goldmont Plus tuning does not. [Intel 356477, Section 6.9, Table 6-19, page 6-48; LLVM 23.1.2, X86.td, line 590; LLVM 23.1.2, X86.td, line 1348; LLVM 23.1.2, X86.td, line 1370; LLVM 23.1.2, X86.td, line 1379]

From Goldmont on, pause waits about as long as on Skylake, to save power in spin loops; see Skylake for what that means for code that spins. [Intel 356477, Sections 6.6 and 6.8.2.17, pages 6-24 and 6-41]

LLVM’s tuning for all four cores loads the operand of push and call into a register first, and prefers movbe to a load and a bswap. [LLVM 23.1.2, X86.td, line 554; LLVM 23.1.2, X86.td, line 1340; LLVM 23.1.2, X86.td, line 857; LLVM 23.1.2, X86.td, line 1346]

Vectors are 128 bits wide and stop at SSE4.2: none of these cores has AVX, so code built for x86-64-v3 does not run on them. On Silvermont only some floating-point units handle a full 128 bits in one pass; from Goldmont on all do. [Agner Fog, Chapter 15, Sections 15.12 and 16.11, pages 182, 186 and 190; Intel 356477, Section 6.8.2.10, page 6-36; LLVM 23.1.2, X86.td, line 1333]

On Silvermont, vector port 0 takes multiplication, division, conversion, shifts, shuffles, string comparison, AES and carry-less multiplication, and port 1 floating-point addition; both run simple vector integer operations. Goldmont also runs shuffles on port 1, and SHA on port 0. [Intel 356477, Section 6.5, Table 6-3, page 6-22; Intel 356477, Section 6.6, Table 6-6, page 6-26]

On Silvermont most packed floating-point operations take a cycle longer than scalar ones and issue half as often: addps 4 cycles, one every 2, mulps 5, one every 2, and mulpd 7, one every 4. Goldmont runs all of them in 3 (add) or 4 (multiply) cycles, one a cycle. [Intel 356477, Section 6.8.2.10, page 6-36; Intel 356477, Section 6.8.2.14, Table 6-14, page 6-38; LLVM 23.1.2, X86ScheduleSLM.td, line 228]

Silvermont and Goldmont divide in 19 cycles for divss, 34 for divsd, 36 to 39 for divps and 66 to 69 for divpd, and the next division can start only a cycle or two before one ends. Goldmont Plus’s radix-1024 divider takes 11, 14, 16 and 22 cycles, and starts the next 4 cycles before one ends. [Intel 356477, Section 6.8.2.10, page 6-36; Intel 356477, Section 6.8.2.14, Table 6-14, page 6-39; LLVM 23.1.2, X86ScheduleSLM.td, line 235; LLVM 23.1.2, X86ScheduleSLM.td, line 240]

Few vector integer instructions run two a cycle on Silvermont, many more on Goldmont. Some go from slow to fast: pshufb from 5 cycles to 1, pmulld from 11 cycles, one every 11, to 5, one every 2, and paddq and psubq from 4 cycles to 2. LLVM’s Silvermont tuning avoids pmulld where other multiplies will do. [Intel 356477, Section 6.8.2.11, pages 6-36 and 6-37; Intel 356477, Section 6.9, Table 6-19, page 6-48; LLVM 23.1.2, X86.td, line 504; LLVM 23.1.2, X86.td, line 1344]

On Silvermont, slow units and microcoded vector instructions often leave little to gain from vectorizing; Goldmont’s faster vector instructions make it pay much more often. Either way, vectorized code should avoid instructions from the microcode ROM. [Intel 356477, Section 6.8.2.12, page 6-37]

An AES round takes 8 cycles, one every 5, on Silvermont, 6 cycles, one every 2, on Goldmont and 4, one a cycle, on Goldmont Plus. pclmulqdq takes 10 cycles, one every 10, on Silvermont and 6, one every 4, on Goldmont. [Intel 356477, Section 6.8.2.13, page 6-37; Intel 356477, Section 6.9, Table 6-19, pages 6-44 and 6-47; LLVM 23.1.2, X86ScheduleSLM.td, line 451; LLVM 23.1.2, X86ScheduleSLM.td, line 456]

Goldmont adds the SHA-1 and SHA-256 instructions, on vector port 0, and rdseed. [Intel 356477, Section 6.6, Table 6-6, pages 6-23 and 6-26; LLVM 23.1.2, X86.td, line 1356; LLVM 23.1.2, X86.td, line 1357]

A floating-point operation with a subnormal input or result, or one that underflows, goes to microcode and takes about 160 cycles on Silvermont and 100 to 200 on Goldmont, unless MXCSR has FTZ and DAZ set and exceptions masked. [Intel 356477, Sections 6.5.2 and 6.8.2.14, pages 6-23 and 6-39; Agner Fog, Sections 15.7 and 16.7, pages 185 and 190]

Moving a value between the integer and the vector units costs 3 to 4 cycles on Silvermont and 4 on Goldmont; mixing integer and floating-point instructions on the same vector data costs nothing, and LLVM’s tuning expects no such delay. [Agner Fog, Sections 15.7 and 16.7, pages 185 and 189; LLVM 23.1.2, X86.td, line 665; LLVM 23.1.2, X86.td, line 1350]

Silvermont decodes two x87 instructions a cycle, unlike the in-order Atom, but SSE arithmetic is still the better choice. Compare with fcomi rather than fcom followed by fnstsw, which comes from microcode. [Intel 356477, Section 6.8.1.2, page 6-32; Intel 356477, Section 6.8.1.1, Table 6-11, page 6-30; Intel 356477, Section 6.8.2.14, page 6-39]

Silvermont does one load or one store a cycle; Goldmont one load and one store, from separate address ports. [Intel 356477, Section 6.6, Table 6-7, pages 6-23 and 6-27]

A cache miss does not stop younger loads: Silvermont keeps up to 8 misses outstanding, and both generations have 8 write-combining buffers. [Intel 356477, Section 6.5, pages 6-20 and 6-22; Intel 356477, Section 6.6, Table 6-7, page 6-27]

Silvermont computes addresses in program order, so a load or store whose address is not ready stalls the younger ones. A memory operation that hits a problem, such as a split line, a blocked forward, a lock or a micro-TLB miss, waits in a side queue and lets younger ones pass; after a store with an unknown address, all later stores go there. [Intel 356477, Section 6.5, page 6-22; Intel 356477, Section 6.8.3.2, page 6-41; Intel 248966, Section 22.2, Table 22-1, page 22-14]

Goldmont lets loads run ahead of older stores whose address is not yet known; when such a store turns out to write the loaded address, the load and what followed it run again, which the event MACHINE_CLEAR.DISAMBIGUATION counts. [Intel 356477, Section 6.6, page 6-26; Intel 356477, Section 6.8.3.2, page 6-41]

A store forwards its data to a later load only when the two begin at one address, the load is no wider, and neither crosses a cache line; otherwise the load waits for the store. The load can run 3 cycles after the store on Silvermont, 4 on Goldmont and again 3 on Goldmont Plus when the stored data comes from a register. [Intel 356477, Section 6.8.3.3, Tables 6-17 and 6-18, pages 6-41 and 6-42; Agner Fog, Sections 15.10 and 16.10, pages 186 and 190]

From Silvermont on, movups, movupd and movdqu are single micro-ops, but a load that splits a cache line costs about 6 cycles. When stepping through an aligned array of floats or dwords at an unaligned index, Intel suggests aligned loads joined by palignr instead. [Intel 356477, Sections 6.8.2.15 and 6.8.3.1, pages 6-40 and 6-41; Intel 356477, Section 6.8.3.5, page 6-42]

Agner Fog saw no cache bank conflicts, but a false dependence between addresses a multiple of 4 KB apart, which Intel’s events count as loads blocked by a 4K alias. [Agner Fog, Sections 15.9 and 16.9, pages 186 and 190; Intel 248966, Section 22.2, Table 22-1, page 22-14]

Silvermont’s address units assume a segment base of 0: a non-zero base costs a cycle, and should be 64-byte aligned. Goldmont handles one a cycle. [Intel 356477, Section 6.8.3.6, page 6-43]

From Silvermont on, prefetchw fetches a line for writing, so that stores to it complete sooner. [Intel 356477, Section 6.8.3.4, page 6-42; LLVM 23.1.2, X86.td, line 1333]

Silvermont has enhanced rep movsb and rep stosb, a good default for copying and filling. rep stos copes with line splits but rep movs does not, so a large copy whose source and destination are misaligned to each other can gain from SIMD code that avoids the splits. [Intel 356477, Section 6.8.3.7, page 6-43]

Code and data should not share a page: Silvermont watches 1 KB regions for writes to code, and a store within 1 KB of code being run clears the pipeline. [Intel 356477, Section 6.8.1.5, page 6-33; Intel 248966, Section 22.2, Table 22-1, page 22-12]

Silvermont adds SSE4.1 and SSE4.2, with popcnt and crc32, and pclmulqdq, prefetchw and rdrand to what the in-order Atom had; Goldmont adds the XSAVE family and fsgsbase besides SHA and RDSEED, and Goldmont Plus adds rdpid and ptwrite, as GCC and LLVM enable them. [Intel 356477, Section 6.5, page 6-20; GCC 14.2, config/i386/i386.h, line 2403; GCC 14.2, config/i386/i386.h, line 2405; GCC 14.2, config/i386/i386.h, line 2408; LLVM 23.1.2, X86.td, line 1333; LLVM 23.1.2, X86.td, line 1377]

The events Intel suggests differ by generation: on Silvermont and Airmont NO_ALLOC_CYCLES and the REHABQ events for back-end and memory trouble, on Goldmont UOPS_NOT_DELIVERED.ANY and MACHINE_CLEAR.DISAMBIGUATION. MS_DECODED.MS_ENTRY counts entries into the microcode ROM. [Intel 356477, Sections 6.8.1.1, 6.8.2.1 and 6.8.3.2, pages 6-31, 6-33 and 6-41; Intel 248966, Section 22.2, Table 22-1, pages 22-10 and 22-14]