The Three-Phase Architecture

Take the problem at face value. You have M source languages and N target architectures, and you want every language to run on every machine. Built naively, that is M times N complete compilers, each containing its own optimizer — and an optimizer is the largest and most subtle part. Adding a language means N new backends; adding an architecture means M new ones.

Now insert one representation in the middle. A frontend translates its language into the shared IR and stops. A backend translates the shared IR into one machine's instructions and knows nothing about any source language. The optimizer is written once, against the IR, and serves everything. Adding a language costs one frontend; adding an architecture costs one backend; every existing language gets the new architecture for free.

That is the whole argument, and it is not a small one. It is why a language released in 2015 could target x86-64, AArch64, ARM, PowerPC, MIPS and WebAssembly on day one with a team of five, and it is the concrete payoff of [[why-ir-exists]] and [[multiple-frontends-one-backend]].

The clean picture hides the part that decides real performance. The backend and the middle-end cannot see the source language, so anything the source language guarantees must be written into the IR explicitly or it does not exist. A frontend that knows signed overflow is undefined must say so on each arithmetic instruction. A frontend that knows two parameters cannot alias must say so with an attribute. A frontend that knows a pointer is aligned, or that a function has no side effects, or that a load is dereferenceable, must say each of those things.

This is why two languages emitting IR for the same algorithm can produce very different machine code. It is not that one optimizer is better — it is the same optimizer — it is that one frontend told it more. Rust's ability to attach aliasing information that a C frontend cannot recover is the clearest example: the information came from the borrow checker, several representations earlier, and the seam is where it gets communicated. See [[rust-pipeline]].

The same argument runs in reverse for what the middle-end cannot express. A language with precise garbage collection needs safepoints and stack maps the IR must be extended to carry; a language with exact exception semantics needs unwind edges modelled; a language with a memory model stricter than the IR's needs to constrain reordering explicitly. Every one of those is a place where a shared representation designed around one family of languages costs the others real work.

It is worth being precise about the limits, because the M+N argument is often stated as though the middle-end made frontends easy. It does not. The frontend is still the entire language: parsing, name resolution, type checking, diagnostics, whatever the language proves before lowering, and the lowering itself. For a language with a sophisticated type system that is the majority of the work, and none of it is shared.

Nor does the shared middle-end do language-specific optimization. Rust runs optimizations on MIR before emitting IR, because facts about ownership and drops are cheaper to exploit while ownership and drops still exist. Swift has SIL for the same reason. Both are admissions that some transformations must happen while the program is still about the source language — and once you accept that, you have a fourth phase, and the tidy diagram has an extra box.

And the backend seam is leakier than it looks. The frontend must already know the target's type sizes, its struct-passing rules and its calling convention, because those decide the IR it emits — a struct passed by value becomes different IR on different ABIs. So the "target-independent" middle is target-independent in its transformations and not in its input, which is why a bitcode file is not a portable program. See [[abi]] and [[target-triples]].