Chapter 15 The Compiler Pipeline on Go: Under the Hood

15.1 Lexing and Grammar

Mon, 01 Jan 0001 00:00:00 +0000

15.1 Lexing and Grammar

The first stop of compilation is turning source text into a structured abstract syntax tree (AST). This takes lexical analysis (slicing a character stream into tokens) and syntactic analysis (organizing tokens into a tree according to the grammar). 3.2 surveyed the whole pipeline from above; this section looks only at its front end, and at why Go’s grammar was designed to be so “easy to parse”.

The package that carries out these two steps is a self-contained part of the compiler, cmd/compile/internal/syntax. It is built from two instruments: the scanner reads characters and emits a token stream; the parser consumes tokens in a recursive descent fashion and builds the syntax tree. The package’s own comments even note with some pride that several of its files, scanner.go, source.go, and tokens.go, do not depend on the rest of the compiler and can be compiled on their own into a standalone library. The reason lexing and grammar can be carved out this cleanly lies in the simplicity of the Go grammar itself.

15.2 Intermediate Representation

Mon, 01 Jan 0001 00:00:00 +0000

15.2 Intermediate Representation

15.1 turned source code into a syntax tree (AST). The AST faithfully records the structure the programmer wrote down: variables, scopes, the nesting of expressions. But the moment we want to optimize, this structure sits too “high.” Consider the most unremarkable line, x = x + 1: in the AST, the x on the left and the x on the right are the same name, and if the compiler wants to know “which assignment produced the value of the x used here,” it has to repeatedly perform scope lookups and data-flow analysis. Names get shadowed, scopes nest, an assignment wipes out the old value, and all of this makes “where a value comes from and where it goes,” which ought to be the most basic thing, murky. What the optimizer wants most is exactly to lay the data flow out in the open.

15.3 The Optimizer

Mon, 01 Jan 0001 00:00:00 +0000

15.3 The Optimizer

15.2 lowered the front end’s syntax tree down to the SSA intermediate representation and explained why SSA’s “each variable is assigned exactly once” makes the optimization passes both accurate and fast to write. This section continues from there: on top of this representation, what optimizations does the compiler actually run, and why precisely these few.

To read the Go optimizer well, we first have to read its disposition. Faced with the same task of turning a high-level language into machine code, GCC and LLVM are willing to spend seconds or even tens of seconds kneading a function over and over to win the last few percent of run-time performance. Go takes a different road: it does only the batch of optimizations with the best cost-to-benefit ratio, and hands the time it saves back to compilation speed (1.1). This is not a shortfall in ability but a clear-eyed ordering of values, and this section will return to that red line at the end. We first look at the optimizations Go is willing to do, then at Profile-Guided Optimization (PGO), introduced in Go 1.21, which pushes optimization from “static guessing” toward “data-driven.”

15.4 The Pointer Checker

Mon, 01 Jan 0001 00:00:00 +0000

15.4 The Pointer Checker

Go is a memory-safe language. In ordinary code, the type system guarantees that every pointer refers to a legal object of its declared type, garbage collection (13) guarantees that an object is not reclaimed while it is still referenced, and the runtime keeps out-of-bounds accesses behind bounds checks. These guarantees are not free. They rest on the premise that the compiler always knows the type and layout of every value. Yet there is always a small set of scenarios that need to step outside this system: interoperating with C (15.6) means interpreting a span of bytes according to C’s memory layout, laying out a system structure for the operating system means placing bytes one by one, and reinterpreting a []byte as a string with zero copies (5.1) means letting two types share the same underlying memory. Go leaves an escape hatch for these scenarios: the unsafe package.

15.5 Escape Analysis

Mon, 01 Jan 0001 00:00:00 +0000

15.5 Escape Analysis

Go programmers never manually decide whether a variable lives on the stack or the heap; the compiler’s escape analysis does it automatically. It is the unsung hero of Go’s performance: keeping as many objects on the stack as possible greatly lightens the load on the garbage collector (13 Garbage Collection). This section explains how it decides, how it is implemented, and why it matters.

15.5.1 Escape: Deciding Stack or Heap

The core question: should a variable be allocated on the stack (vanishing automatically when the function returns, at zero GC cost) or on the heap (with an indefinite lifetime, managed by the GC)? The criterion is lifetime: if a reference to a variable may still be used after the function returns, it cannot live on the stack (the stack frame is destroyed on return) and must escape to the heap. Escape analysis answers this question statically, deciding whether a variable’s address can leave the scope of the function it lives in.

15.6 cgo

Mon, 01 Jan 0001 00:00:00 +0000

15.6 cgo

“cgo is not Go.” This is the verdict Rob Pike handed down on cgo in a blog post. It names a thing that is easy to overlook: when you write import "C" in a Go source file and then write a single line of C.foo(), you have already stepped out of the world that the Go language drew for you and into another world, one made of C’s ABI, C’s stack, and C’s memory model. cgo is the bridge between these two worlds. The bridge is useful, but crossing it costs a toll, and the toll is not cheap.

15.7 Past, Present, and Future

Mon, 01 Jan 0001 00:00:00 +0000

15.7 Past, Present, and Future

The compiler is the part of the Go toolchain that changes most often, yet remains the most transparent to users. Take the same source code, change nothing, recompile it with a new version, and it often comes out faster, smaller, and better, without you ever knowing what happened in between. This section pulls the camera back to look at the road the compiler itself has traveled, then at what it is doing now and where it is heading next. Running through all of it is one unchanging order of priorities: compilation speed comes first, quality of generated code second, and both are traded off under the constraint of being engineerable (1.1).