the compiler pipeline

Think of a factory line. Your source text goes in one end as the characters you typed, and machine code comes out the other end, but it does not happen in one magic step. It moves through a series of stages, and each stage transforms the program into a slightly more machine-like form than the one before. That ordered series of stages is the compiler pipeline.

The pipeline is conventionally split into three big regions. The front end reads the source language (say, C or Rust), checks that it is well-formed, and turns it into an internal intermediate representation, or IR — a neutral data structure the rest of the compiler works on rather than raw text. The middle end runs optimization passes that rewrite that IR into a faster but equivalent IR. The back end then lowers the IR to the actual instructions of the target processor: it picks instructions, decides their order, assigns registers, and emits the final code. A key idea is that the IR sits in the middle so that many source languages can share one optimizer and one optimizer can target many processors.

It matters because almost every confusing thing a compiler does — why it deleted your check, why your code got 'reordered', why a bug only appears at -O2 — is really something a specific stage of this pipeline did. Knowing which stage owns which job lets you ask the right question. One honest caveat: real compilers are messier than three clean boxes. Stages blur, the IR is lowered gradually through several forms, and a single -O2 run may visit dozens of passes many times over.