a compiler pass

Think of editing an essay by making one focused sweep at a time: one read-through to fix spelling, another to tighten wordy sentences, another to check the facts. Each sweep has a single job and hands a cleaner draft to the next. A compiler pass is exactly that: a single, self-contained step that walks over the program's IR to do one specific thing.

Passes come in two flavors. A transform pass rewrites the IR — for example, the inliner, the dead-code eliminator, or the loop unroller each take IR in and produce changed IR out. An analysis pass does not change anything; it computes facts the transform passes need, like 'which values are constant' or 'which definitions reach this use'. The optimizer is built as a pass pipeline: an ordered list of passes that run one after another, with analyses feeding transforms. Order and repetition matter a lot — inlining a function exposes constants for the next folding pass, so optimizers run certain passes multiple times to chase the opportunities each one reveals.

It matters because the modular pass design is why compilers are maintainable and why you can reason about them: each pass does one understandable thing, and you can even ask a compiler to run a single named pass. It also explains the cost of optimization — running more passes (and running them again) takes compile time. A caveat: a pass is correct only if it preserves observable behavior, and the order is not arbitrary; a badly ordered or buggy pass can pessimize code or, in rare cases, miscompile, which is why compilers carefully fix and test their default pipelines.