What Dies at Each Stage

The usual telling of the pipeline is additive: tokens add grouping, trees add structure, types add meaning. The additive story explains how compilation works and explains none of the things engineers actually hit. Read the same rail as a list of deletions and the entire tooling landscape becomes predictable.

Every row below has a tool built to undo it, and every one of those tools has a cost that shows up somewhere else — in build time, in artifact size, in optimization quality, or in an approximation that is wrong just often enough to mislead.

The remedy for most of the list is to emit a parallel representation that records the mapping from what the machine will do back to what the developer wrote. In native toolchains that representation is DWARF, and it is genuinely large: line tables, variable location lists describing which register or stack slot holds each variable *at each instruction range*, type descriptions, and the inlining tree needed to reconstruct a call stack that no longer physically exists.

It is worth internalising that a variable location is a function of the program counter, not a fact. After optimization, x might be in rbx for one instruction range, in a stack slot for another, and nowhere at all for a third because its value is recomputable and the compiler chose not to keep it. DWARF can express all three. What it cannot express is a value that was never computed, which is why some variables are honestly unavailable rather than merely hidden.

The cost is real and often surprising: debug sections routinely exceed the size of the code they describe, which is why release builds strip them into separate files — .dSYM bundles, .pdb files, debuginfod servers — and why [[symbolication]] is a deployment concern rather than a debugging one.

Engineers usually read "optimized out" as the debugger failing. It is more often the debugger being truthful about a program in which the variable does not exist at that point.

Consider a local whose value is used once, immediately, in the next instruction. The compiler may keep it in a register that is overwritten straight afterwards; it may never materialise it at all, folding the computation into the instruction that consumes it; or it may have proved the whole computation dead and deleted it. In the first case the value exists briefly and DWARF can describe when. In the second it exists only as part of another instruction's operand. In the third it never existed. All three report as unavailable, and only the first is recoverable in principle.

This is why [[debug-vs-release]] is a real decision rather than laziness. Building at -O0 with -g keeps every variable in a stack slot for its whole scope, which makes the debugger tell you everything and makes the program slower by a factor that varies enormously. The middle option — -Og, or optimized builds with full debug information — is a genuine compromise and behaves like one.

Some information is not merely discarded but was never expressible. Intent is the main one: the compiler knows that a loop sums an array, and does not know that the array is a customer balance and the sum must not silently overflow. Comments are gone by the second stage and no metadata format carries them. Variable names survive only as labels, which is why a decompiler produces correct code with names like v3 — the semantics were preserved perfectly and the meaning was not.

This is the honest limit of the whole enterprise, and it is why source remains the artifact of record. A binary is a complete description of what will happen and a poor description of what was meant, and every review process, every test suite and every comment exists on the source side of that gap for exactly this reason.