Register Deprivation: Spills and Runtime under Forced Register Scarcity

Environment: Intel Xeon E-2236 @ 3.40GHz | Compiler: gcc 15.2.0 | Date: 2026-07-13

This study examines the impact of artificial register pressure. By utilizing the gcc -ffixed-reg flag, the researchers progressively reserved registers to shrink the available pool, subsequently measuring the resulting spill counts and execution times across nine distinct kernels.

TL;DR: Restricting register availability slowed 8 out of 9 kernels by between $14\%$ and $76\%$ at the most constrained budget. SipHash was the sole exception, showing no performance degradation.

The source code is available at https://github.com/rjpower/spillbench, with raw data stored in results.json.

Key Findings

Consistency: All results remained bit-identical regardless of the register budget; the reservation affected the instructions generated, not the mathematical outcome.
Correlation: There is a weak correlation between the number of additional spill instructions and the resulting slowdown (Pearson $r = 0.55$ across 105 data points).
Variability: The "cost" of a single spill varies wildly—from $\approx 0\%/\text{spill}$ (SipHash) to $2.2\%/\text{spill}$ (FIR filter), a difference of roughly $30\times$ .
Cross-File Impact:
- For SHA-256, reserving XMM registers increased runtime by $+5.6\%$ , while reserving GP registers caused a $+33\%$ hit.
- For Double Precision Matmul, reserving GP registers had no effect, but reserving XMM registers caused a $+34\%$ slowdown.
- Note: SHA-256 is an integer kernel, but because gcc auto-vectorizes parts of it using SSE at -O2, XMM reservation is not inert (spills rose from $8 \rightarrow 65$ ).

Experimental Setup

The researchers tested two primary hypotheses:

H1: Reducing the register count will monotonically increase spills and decrease performance.
H2: Performance degradation will only occur when the register file actually utilized by the kernel (GP for integer, XMM for float) is restricted.

Methodology

The team used gcc -ffixed-reg to remove registers from the allocator's pool for the entire compilation process. Each kernel was recompiled for every budget increment.

GP Register Removal Order: r15 $\rightarrow$ r14 $\rightarrow$ r13 $\rightarrow$ r12 $\rightarrow$ rbp $\rightarrow$ rbx $\rightarrow$ r11 $\rightarrow$ r10 $\rightarrow$ r9 $\rightarrow$ r8 (Reducing the pool from 15 allocatable registers down to 5; rsp is always excluded).

Constraints: ABI registers (e.g., rax, rcx, rdx, rsi, rdi, and xmm0–3) were never reserved, as they are essential for argument passing and specific instructions like mul.

The Test Suite

Six kernels targeted the General Purpose (GP) file, and three targeted the XMM file.

Kernel	File	Description	Validation Method
ChaCha20	GP	20-round stream cipher (16 $\times$ 32-bit state)	RFC 8439 §2.3.2
SHA-256	GP	Compression function (8 vars + 64-word schedule)	SHA-256("abc")
SipHash-2-4	GP	Keyed hash (4 $\times$ 64-bit ARX)	Reference vector
Integer matmul	GP	4 $\times$ 4 register-blocked int64 micro-kernel	vs. naive triple loop
LZ77 compress	GP	Hash-chain match finder	Round-trip (comp $\rightarrow$ decomp)
Quicksort	GP	In-place recursive int32 sort	Output verification
Double matmul	XMM	4 $\times$ 4 register-blocked f64 micro-kernel	vs. naive triple loop
FIR filter	XMM	16-tap filter (8 output lanes)	vs. naive tap sum
Mandelbrot	XMM	Escape-time (few live doubles per pixel)	Known escape counts

Measurement Process

Spill Metric: Static analysis via objdump counting instructions referencing a fixed stack slot (e.g., ...(%rsp)), excluding array indexing.
Timing: Performed on a single pinned core.
Hardware: Intel Xeon E-2236 @ 3.40 GHz, gcc 15.2.0, -O2 -fPIC -shared.
Constraint: Hardware performance counters were unavailable (perf_event_paranoid=4).

Result 1: Impact of Register Removal

Most kernels slowed down as registers were removed, though SipHash-2-4 remained unaffected.

Figure 2: Runtime trends for integer and float kernels.

Slowdown at Maximum Constraint:

Kernel	File	Runtime (Full $\rightarrow$ Min)	Slowdown	Spills (Full $\rightarrow$ Min)
FIR filter	XMM	$135.5 \rightarrow 238.9\text{ ms}$	$+76\%$	$8 \rightarrow 43$
Integer matmul	GP	$140.5 \rightarrow 199.7\text{ ms}$	$+42\%$	$60 \rightarrow 82$
Double matmul	XMM	$131.5 \rightarrow 176.4\text{ ms}$	$+34\%$	$66 \rightarrow 100$
SHA-256	GP	$89.4 \rightarrow 119.0\text{ ms}$	$+33\%$	$8 \rightarrow 80$
Quicksort	GP	$134.2 \rightarrow 171.7\text{ ms}$	$+28\%$	$4 \rightarrow 49$
ChaCha20	GP	$88.5 \rightarrow 110.0\text{ ms}$	$+24\%$	$55 \rightarrow 121$
LZ77 compress	GP	$123.2 \rightarrow 146.8\text{ ms}$	$+19\%$	$39 \rightarrow 115$
Mandelbrot	XMM	$101.6 \rightarrow 116.2\text{ ms}$	$+14\%$	$0 \rightarrow 7$
SipHash-2-4	GP	$79.4 \rightarrow 78.1\text{ ms}$	$-2\%$	$0 \rightarrow 23$

Analysis of H1: H1 is ~~fully supported~~ partially supported. While the general direction is correct (fewer registers $\approx$ slower code), the relationship is not strictly monotonic.

Spill anomalies: ChaCha20 and Quicksort both saw static spill counts drop after a register was removed in certain steps.
Runtime noise: Local dips occurred in LZ77 (5 steps), SipHash (3 steps), and Quicksort (3 steps), often within the $\approx 1\%$ measurement noise.
Initial State: Integer matmul began with 60 spills even with a full register file because its $4\times 4$ block requires 16 int64 accumulators, exceeding the 15 available GP registers.

Result 2: Spill Count as a Predictor

The number of added spills is a poor indicator of actual performance loss.

Correlation Analysis: Across all 105 test points, the Pearson correlation coefficient is $r = 0.55$ .

Cost Per Added Spill:

Kernel	Added Spills (Min)	Total Slowdown	Slowdown per Spill
FIR filter	$+35$	$+76\%$	$2.18\%/\text{spill}$
Mandelbrot	$+7$	$+14\%$	$2.05\%/\text{spill}$
Integer matmul	$+22$	$+42\%$	$1.92\%/\text{spill}$
Double matmul	$+34$	$+34\%$	$1.00\%/\text{spill}$
Quicksort	$+45$	$+28\%$	$0.62\%/\text{spill}$
SHA-256	$+72$	$+33\%$	$0.46\%/\text{spill}$
ChaCha20	$+66$	$+24\%$	$0.37\%/\text{spill}$
LZ77 compress	$+76$	$+19\%$	$0.25\%/\text{spill}$
SipHash-2-4	$+23$	$-2\%$	$\approx 0\%/\text{spill}$

Observation: The disparity is stark: Integer matmul suffered a $+42\%$ slowdown with only 22 extra spills, whereas LZ77 added 76 spills but only slowed by $+19\%$ .

Example of a spill instruction identified by objdump:

movq    %rax, -8(%rsp)  # Store register to stack
movq    -8(%rsp), %rdx  # Reload from stack

The researchers conclude that the explanation for this variance likely lies in... [Article ends here]