Why Debug Info Makes Rust-to-WebAssembly Builds 40x Slower

Compiling Rust to WebAssembly with debug info (debug = 2) can be tens of times slower than the same build without it — in some cases over 40x. A minimal 40-line reproducer shows build time jumping from 1.5 seconds to more than 50 seconds simply by enabling full DWARF debug data.

The root cause is LLVM's WebAssembly-specific 'Register Stackify' pass, which moves values onto the wasm operand stack and must also relocate their associated DBG_VALUE debug records. Because WebAssembly is a stack machine, a large amount of code gets moved, and the pass repeatedly rescans a list of records that keeps growing — turning what should be linear work into quadratic overhead, while leaving stale records behind instead of deleting them.

A similar LLVM bug was already fixed for clang, but that fix doesn't fully solve the Rust/WebAssembly case: after enough relocations, a debug record can end up pointing at a register defined further down the block. A forward-only scan can never reach it, so the optimization's exit condition is never satisfied.

A more complete patch adds both forward and backward scanning, skips unnecessary position lookups for debug records, and introduces a cheaper WebAssembly-specific ordering check — cutting hash-table lookups in the reproducer from 27.4 million to 3 million. This matters for engineers targeting wasm, since anyone relying on debug builds for profiling or troubleshooting sees compile times directly hit their iteration speed.