LLVM
Engineer
Roadmap

Frontend → Optimizer → Backend. N languages × M targets = N+M components, not N×M. This is the entire reason LLVM exists. Read the AOSA chapter by Chris Lattner — it's 20 pages that reframe how you think about tools.

IR is a RISC-like assembly language with infinite virtual registers, strong typing, and no hardware assumptions. It's what lets the optimizer work independently of both the source language and the CPU. Your x86-64 knowledge transfers — IR is just a cleaner ISA.

GCC is a monolith — frontend and backend are tightly coupled. Clang is a library-based frontend that emits LLVM IR. Understand why this matters for tooling, IDE integration, and static analysis.

Your entry point. Key flags to know: -emit-llvm (output IR), -S (text form), -O0/-O2/-O3 (optimization levels), -c (object file). Practice: compile a C file to IR, to assembly, and to object code using only clang flags.

Takes .ll files, runs passes, outputs optimized .ll. Learn: -passes="mem2reg,dce", --print-changed, -stats. This is the tool you'll use most in Phase 4 when writing your own passes.

Converts IR to machine code. Key flags: -march (target arch), -filetype=asm vs obj. Try targeting a different arch than your host to feel what "hardware independence" actually means.

Set up a permanent workflow: left pane = C source, right pane 1 = clang x86-64, right pane 2 = clang LLVM IR. Highlight a C expression and see both outputs highlight simultaneously. This dual-map exercise will rewire how you think about code.

Runs .ll files directly. Not for production, but essential for learning IR: write it, run it, see the result. No compilation step required.

Write a factorial function in C. Generate both x86-64 ASM and LLVM IR. Write a 1-page comparison: What's similar? What's different? (Hint: IR has no memory, no stack frame in SSA form. x86-64 has rbp, rsp. Find where IR uses alloca and why.)

Every variable is assigned exactly once. If you need to reassign, you create a new variable. This sounds crazy at first, but it makes data-flow analysis trivially simple. Compilers can prove "this value never changes" without complex analysis.

The one hard part of SSA. When control flow merges (after an if/else), which version of a variable do you use? The phi node selects based on which basic block you came from. Critical to understand before Phase 4.

Clang at -O0 doesn't generate SSA directly — it generates alloca/store/load. The mem2reg pass promotes these memory operations to SSA registers. This is why unoptimized IR looks messy: it's designed to be simple to generate, then cleaned up.

IR is strongly typed. Master: i1, i8, i32, i64 (integers), float, double, ptr (opaque pointer — modern LLVM), [N x T] (arrays), {T1, T2} (structs), T(T1, T2)* (function pointers).

Must know: alloca (stack), load/store, add/sub/mul/sdiv, icmp/fcmp, br (conditional and unconditional), call/ret, getelementptr (GEP — pointer arithmetic), bitcast/trunc/zext/sext.

GEP is pointer arithmetic, not a memory access. It calculates an address — it does NOT dereference. This trips up everyone. The first index dereferences the pointer type, subsequent indices navigate struct/array fields. Study at least 5 examples before moving on.

A function is a collection of basic blocks. Each block ends with a terminator (br or ret). Edges between blocks form the CFG. Every optimization in LLVM operates on this graph structure. Draw CFGs by hand for small functions.

Don't read it cover to cover. Learn to navigate it. Every time you see an instruction you don't know, look it up. Bookmark the sections: Type System, Instruction Reference, Intrinsics. You'll consult this daily.

Write a complete binary search function in LLVM IR by hand (no clang). Include: loop with phi nodes, array access via GEP, comparison + branch, return value. Run with lli. This is the IR equivalent of writing assembly from scratch — it will hurt once and teach forever.

Convert raw text into a stream of tokens (keywords, identifiers, numbers, operators). Write a hand-rolled lexer — no lex/flex. Kaleidoscope's lexer is ~100 lines of C++. Key: every token needs a type and a value.

Convert tokens into an AST. Recursive descent is the industry standard for hand-written parsers. Each grammar rule becomes a function. Kaleidoscope uses Pratt parsing for expressions (precedence climbing). Learn both.

Design your AST classes: ExprAST (base), NumberExprAST, VariableExprAST, BinaryExprAST, CallExprAST, FunctionAST. Each node must have a codegen() method that returns an llvm::Value*. This interface is the bridge between frontend and backend.

LLVMContext owns all IR objects. Module is a compilation unit (a .ll file in C++ form). IRBuilder is your "cursor" — it tracks the current insertion point and has methods for every instruction. You'll use these in every compiler you ever write.

Map each AST node to IRBuilder calls: CreateAdd/Sub/Mul, CreateFCmpOLT (float compare), CreateBr/CreateCondBr, CreateCall, CreateRet, CreateAlloca, CreateStore/Load. Practice until you can translate IR syntax to C++ API calls without looking it up.

Function::Create() with FunctionType. BasicBlock::Create() and setting the IRBuilder insertion point with SetInsertPoint(). Handle function arguments with func->arg_begin(). This pattern repeats in every backend codegen.

ORC (On-Request Compilation) is LLVM's composable JIT framework. Key layers: IRCompileLayer, RTDyldObjectLinkingLayer. For Kaleidoscope, you add functions to the JIT incrementally as the user types them. This mirrors how REPLs work.

JIT needs to find symbols (like sin, printf). Learn how symbol lookup works: JIT → process symbols → stdlib. Implement extern declarations in your language so Kaleidoscope can call C functions.

Finish all 7 chapters of the official tutorial. Then add ONE feature that isn't in the tutorial: string literals, a for loop, user-defined operators, or mutable variables. This extension forces you to truly understand the system rather than follow along.

LLVM switched from the Legacy Pass Manager to the New Pass Manager (NPM) in LLVM 13+. All new code uses NPM. Key types: FunctionPass, ModulePass, LoopPass. Pass registration with PassPluginLibraryInfo for out-of-tree passes.

Every pass implements a run(Function &F, FunctionAnalysisManager &AM) method. It returns PreservedAnalyses — telling the pass manager which analyses are still valid after your transformation. Returning PreservedAnalyses::all() vs none() has performance implications.

Walk functions, basic blocks, and instructions. Pattern: for (BasicBlock &BB : F), for (Instruction &I : BB). Learn to use dyn_cast<BranchInst>(&I) for instruction type checking. This is boilerplate you'll type hundreds of times.

A block A dominates B if every path to B goes through A. Crucial for: finding where to hoist code, validating SSA, loop analysis. Access via DominatorTree &DT = AM.getResult<DominatorTreeAnalysis>(F).

Can two pointers point to the same memory? If not, loads/stores can be reordered. AliasAnalysis returns MustAlias, MayAlias, or NoAlias. Fundamental for auto-vectorization and memory-level parallelism.

Write a pass that identifies unreachable basic blocks (blocks with no predecessors in the CFG, excluding the entry block) and instructions with no users that also have no side effects. Print a report. This teaches you CFG traversal + use-def chains.

The most important optimization pass. Replaces instruction patterns with cheaper equivalents. Examples: x * 2 → x << 1, x + 0 → x, x / 2 → x >> 1 (unsigned). Study the existing instcombine source — it's 50k lines of patterns and teaches you how to think about transformations.

Remove instructions whose results are never used. ADCE (Aggressive DCE) also removes unreachable blocks. Implement a basic DCE: iterate instructions in reverse, if I.use_empty() and instruction has no side effects, erase it.

LICM (Loop-Invariant Code Motion): if a computation's inputs don't change in a loop, hoist it outside. Loop Unrolling: replicate loop body N times to reduce branch overhead. Loop Vectorization: convert scalar loops to SIMD. These are where most performance gains come from in real-world code.

Write a pass that finds multiply-by-power-of-2 patterns (mul i32 %x, 4) and replaces them with shifts (shl i32 %x, 2). Extend to handle division. Test with opt --load-pass-plugin=./libMyPass.so -passes="strength-reduce".

Replace a function call with the function body. Eliminates call overhead and enables further optimizations across call boundaries. Learn the inlining cost model: LLVM uses a heuristic based on instruction count. InlineFunction() utility in LLVM API.

SmallVector<T, N>: vector with N elements on the stack before heap allocation. Avoids allocations for small collections (most compiler data). ArrayRef: non-owning reference to any array-like container. Use these everywhere in compiler code — never raw std::vector for IR-level work.

StringRef: non-owning reference to a string — zero-copy. Twine: lazy string concatenation tree. Never allocate intermediate strings in hot paths. Profilers hate std::string in compilers.

Hash maps/sets optimized for pointer keys (common in IR — Value*, BasicBlock*). Much faster than std::unordered_map for small-to-medium sizes due to open addressing and cache locality.

Every Value in LLVM has a list of uses. Iterate with for (Use &U : V.uses()). Replace all uses with V.replaceAllUsesWith(NewV). This is the foundation of every transformation — finding what uses what.