Compiler Engineering in Practice

This resonates with how compiler work looks outside textbooks. Most of the hard problems aren’t about inventing new optimizations, but about making existing ones interact safely, predictably, and debuggably. Engineering effort often goes into tooling, invariants, and diagnostics rather than the optimizations themselves.

  Why compilers are hard – the IR data structure

  Compilers do have an essential complexity that makes them "hard" [...waffle waffle waffle...]

  The primary data [...waffle...] represents the computation that the compiler needs to preserve all the way to the output program. This data structure is usually called an IR (intermediate representation). The primary way that compilers work is by taking an IR that represents the input program, and applying a series of small transformations all of which have been individually verified to not change the meaning of the program (i.e. not miscompile). In doing so, we decompose one large translation problem into many smaller ones, making it manageable.

  Why compilers are manageable – the IR data structure

The compiler part of a language is actually a piece of cake compared to designing a concurrent garbage collector.

Always interested in compiler testing, so I look forward to what he has to say on that.

> What is a compiler?

Might be worth skipping to the interesting parts that aren’t in textbooks

“Compiler Engineering in Practice” is a blog series intended to pass on wisdom that seemingly every seasoned compiler developer knows, but is not systematically written down in any textbook or online resource. Some (but not much) prior experience with compilers is needed.

skimmed through the article and the structure just hints at being not written by a human