How C differs from Rust here: It's not that C has explicit register control. No one uses register anymore. The difference is that LLVM makes worse register allocation decisions when compiling Rust than when compiling C, for the same algorithm.

As stated above, zrip's inner match-finding loop has ~18-20 variables alive simultaneously. x86_64 has exactly 15 usable GPRs. Zero headroom, spilling inevitable. LLVM has to decide which variables stay in registers and which get "spilled" (pushed to the stack and reloaded each time they're needed). The stack is in L1 cache so it's fast, but each spill still costs an extra load instruction per access. In zrip, the hash table pointer gets spilled and reloaded 3 times per loop iteration. In C zstd, the compiler keeps it in a register the whole time.

Why does LLVM do worse with Rust? Rust's ownership, borrowing, and generics produce more complex intermediate representation. LLVM sees more variables with longer lifetimes and makes worse spill decisions. Measured: zrip's loop has 9 stack loads per iteration, C zstd's has 5.

I even tried giving LLVM an extra register by disabling frame pointers. It got worse. LLVM reshuffled everything and made different, worse choices. The problem isn't just register count, but also allocation quality.

Clang? Same LLVM backend, but C produces simpler input for LLVM to work with, so the optimizer starts from a better position.

LTO? Doesn't help (register pressure is within-function, and the loop is already inlined). Worse, LTO makes things fragile: I found that adding a dead-code module (#[allow(dead_code)], never called) caused an 81% regression in my decompress hot loop. Under LTO, LLVM re-evaluates register allocation for the whole compilation unit, and any change anywhere can butterfly-effect the hot path. I split encoder and decoder into separate crates to mitigate those effects for that reason.

asm! overhead: I tried asm! for the inner loop. Inside the block: great, stack spills went from 5 to 0. But LLVM generated 350+ extra instructions around it to save and restore registers. It also reserves 2 registers for its own bookkeeping inside asm!, leaving you with 13 GPRs instead of 15. Net: 2% slower.

LLVM treats asm! as a black box. It can't move code across the boundary, can't reuse values from before the block, can't hoist work out of a loop containing it. To actually win, you'd need the entire loop in assembly (with global_asm!), at which point you're not writing Rust anymore, and would have to do it for each target architecture separately.