DEV Community: Reginald Ojunga

NASA Power of 10 rules

Reginald Ojunga — Thu, 10 Sep 2026 08:53:21 +0000

So if you have been in the programming space long enough, you have
probably heard of Nasa's Power of 10 rules.
And these are basically a set of rules that lower chances of software
failure in mission critical software.

The first is simplify control flow. This isn't particularly an issue especially for those using current high level languages. I frankly do not know what the fuss is all about on gotos.

Provide an explicit iteration upper bound. Prevent the software from entering into an endless loop.

No dynamic memory allocation after initialization. I am uncertain how programs that perform strict static allocation handle inputs at runtime. On the upside it obviously makes sense a dynamic allocation translates to a syscall. You want to avoid those if you are trying to be fast.

Use short functions. This i believe is to help in developer experience by reducing complexity.

Use assertions. Assertions come in a set that involve either checking the value, property of the value or the value's location in memory. These are some of the ways of checking for equivalence.
And basically the purpose of assertions is to act as in-flight checks. They add a layer of redundancy.

Declare all data at the smallest scale possible. I believe this speaks to the need for performance. Smaller data structures are almost equivalent to what may be deemed as cache-conscious data structures.
They are good for both spatial and temporal locality and as a consequence they prevent cache thrashing.

Check the return value of all non-void functions. I think this can be done using assertions.

Limit pointer use. No more than one dereference. I think extensive use of pointers in any given program
is equivalent to playing russian roulette.

Finally always compile with all warnings enabled.

Most of these rules have been adopted and used to build different development cultures like Tiger Style.
Things like static allocation have been used to explain tigerbeetle's high performance.

There's a full length video on this by Gerald Holzman.

Inside LLVM: Engineering a Target-Independent Compiler(3)

Reginald Ojunga — Mon, 24 Aug 2026 10:14:05 +0000

Part 3 — Reusing Optimizations Across Architectures

The Middle-End

1. The Question

Parts 1 and 2 established two foundational abstractions. LLVM is organized as a collection of
reusable libraries rather than a monolithic compiler, and LLVM IR serves as the stable contract
that lets many languages feed a single optimizer.

I hope it is clear by now what the IR is. It is just a data structure that eases the process of reorganizing code structure into what its equivalent hand-written assembly would look like. This means that ideally performing optimizations on the written code is not particularly expensive. In the next few sections, this will be illustrated, hopefully without bringing about much confusion.

A new question now arises.

If the same IR is produced by frontends as different as Clang, Rustc, and the Swift compiler, why
should the same sequence of optimizations improve all of them? More precisely:

Why can the same optimization improve programs written in completely different languages and still produce good code for completely different processors?

The answer lies in what the middle-end (the contract - LLVM IR) abstracts away.

2. The Limitation

Once a program has been lowered to LLVM IR, a large collection of analyses and transformations
become possible:
dead-code elimination, common-subexpression elimination, sparse conditional constant propagation,
loop-invariant code motion, inlining, vectorization, and many others.

If each of these transformations had to be written with intimate knowledge of a particular
language or a particular micro-architecture, the reuse promised by Parts 1 and 2 would collapse.
An inliner that understood Rust’s ownership semantics would be useless for C. A loop optimizer that
hard-coded the characteristics of an Intel Golden Cove branch predictor would generate poor code
for an ARM Neoverse core or a simple in-order RISC-V microcontroller.

This therefore imposes a new engineerining hurdle:

The IR has to be sufficiently composable to allow the middle-end to improve code without knowing the source language that produced the IR and without
knowing most of the micro-architectural details of the processor that will eventually execute it.

Traditional optimizers often failed this test. Many were deeply entangled with the frontend that fed them
or with the backend they fed. The result was duplicated effort and optimizations that were not portable.

3. The New Abstraction

LLVM’s response is a suite of analyses and transformations that operate almost
exclusively on the properties of LLVM IR itself, together with a narrow, carefully controlled set of target
queries.

The optimizer is allowed to rely on:

LLVM-IR SSA property,
the explicit control-flow graph as exposed by BasicBlocks and TerminatorInstructions,
the type system,
the use-def chains,
and a small number of target descriptors (DataLayout, TargetLibraryInfo, TargetTransformInfo).

It is not allowed to assume:

a particular finite register file,
a particular pipeline depth or issue width,
the presence or accuracy of a branch predictor,
a particular memory-reordering model,
or the existence of speculative execution with specific side effects.

Assumptions that are implementation specific.

By relying on a general infrastructure (LLVM-IR itself), the same pass can run on IR that originated in C, Rust,
or Swift and later be lowered to x86-64, AArch64, or RISC-V.

I think it is quite accurate to say that the IR explicitly refuses to rely on
specific information unless it is absolutely neccessary.

4. How It Works

The middle-end is organized as a pipeline of passes. Each pass is either an analysis
(computing information such as dominator trees, loop nests, or alias sets) or a transformation
(rewriting the IR while preserving semantics). These are source to source transformations.
They modify LLVM-IR.

Modern LLVM uses the New Pass Manager. Analyses are requested on demand and cached; transformations
declare which analyses they preserve or invalidate. This machinery lets the compiler avoid recomputing
expensive results and keeps the pipeline composable.

Two further design decisions keep the middle-end largely target-independent.

Canonicalization

Many passes exist solely to drive the IR toward a smaller set of preferred forms. InstCombine, SimplifyCFG,
and related passes rewrite instruction sequences into canonical patterns so that later passes see less
surface variation. Canonical forms are chosen because they are easier to reason about, not because they
match any particular machine. They are equivalents of irreducible facts at the instruction level.

Controlled target queries

When a pass truly needs hardware knowledge—most often for cost modeling—it consults TargetTransformInfo (TTI) or
TargetLibraryInfo (TLI). Vectorizers ask TTI about legal vector widths and the relative cost of shuffles. The inliner
may ask about call overhead. These queries are deliberate, narrow leaks; the great majority of transformations never
make them. These are the abstraction leaks spoken of in the first phase of the series.

What the IR Abstracts Away

LLVM IR presents a simplified model of execution that deliberately erases many hardware realities:

Infinite virtual registers. Real processors have small, architecturally visible register files and must spill. The middle-end largely ignores this constraint; register allocation occurs later.
Simple control flow. IR has basic blocks and terminators. It does not expose branch-predictor tables, return-address stacks, or the speculative execution machinery that modern CPUs use to keep pipelines full.
Sequential consistency within a thread (with explicit atomics). Real machines reorder loads and stores. x86 provides a relatively strong model; ARM and RISC-V provide weaker models that require more barriers. The middle-end works with the IR’s memory model and leaves the insertion of the precise fences to later stages or to target-specific lowering.
Uniform instruction costs. An add in IR is just an add. On a real machine its latency, throughput, and ability to execute on multiple ports vary dramatically. Only cost-model-driven passes consult TTI for this information.

Concrete Architectural Differences the Middle-End Mostly Ignores

Consider three capabilities that hardware exposes to varying degrees and that aggressive programmers
sometimes exploit directly.

Branch prediction and speculative execution

High-performance x86 and ARM cores invest heavily in predictors and execute far beyond
unresolved branches.
A misprediction is expensive, so the shape of control flow matters. Some code bases
are hand-tuned to make branches more predictable or to use conditional moves to avoid them.
LLVM IR has no first-class notion of “this branch is highly predictable” or “this value was produced by speculation.”
The middle-end may convert branches into selects (or vice versa) based on simple heuristics
and TTI cost models, but it does not try to model predictor state. The final decision about
branch versus conditional move is left to the backend, where target-specific knowledge is available.

Instruction reordering and out-of-order execution

Out-of-order cores (most modern x86 and high-end ARM designs) dynamically reorder independent instructions to
hide latency. In-order cores (many embedded RISC-V implementations, older ARM cores) do not.
The middle-end performs static reordering only when it is profitable under a simplified cost model;
it does not attempt to schedule for a particular out-of-order window or reservation-station
configuration. Those decisions belong to the machine scheduler, which runs after instruction
selection and has access to detailed pipeline models.

Explicit software pipelining or prefetching

Some architectures and some performance-sensitive code sequences rely on software pipelining or
on explicit prefetch instructions. LLVM IR has no direct encoding of “this load should be issued
two iterations early.” Loop transformations may create the conditions under which a later backend
can software-pipeline, but the middle-end itself does not emit architecture-specific prefetch
intrinsics unless a pass has been told (via TTI or target hooks) that they are profitable.

In each case the IR and the middle-end provide a portable substrate. Such features that differ most
across micro-architectures are relegated to later stages and often accessed through narrow interfaces, or are left entirely
to the backend.

5. Design Trade-offs

This abstraction of hardware details buys massive reuse: the same LoopVectorize pass, the same GVN,
the same inliner, improve C, Rust, and Swift alike, and the resulting IR can be handed to any LLVM
backend. Even extensive polyhedral optimizations that improve data locality exposing pockets of parrallelism
become possible for a whole set of architectures.

Obviously, the cost is that some optimization opportunities are left on the table until later stages,
and a few must be handled by target-specific passes. A purely target-agnostic middle-end cannot,
for example, know that a particular sequence will saturate a specific execution port on a
particular CPU, nor can it know the exact misprediction penalty of a given branch.

LLVM accepts this trade-off because the alternative—writing and maintaining separate optimization pipelines for every
language and every major micro-architecture re-introduces the N × M problem that Part 1 set out to describe.

6. The Abstraction Leaks

The middle-end is only mostly target-independent. Three important leaks exist:

DataLayout — already present in the IR (Part 2). Alignment and pointer-size decisions affect many optimizations.
TargetLibraryInfo — tells the optimizer which library calls exist and what they mean (e.g., whether memcpy may be assumed, or whether a math function is available).
TargetTransformInfo — the primary channel for cost modeling. Vectorization, inlining heuristics, and some simplification decisions consult it.

In addition, a few passes are allowed to behave differently when they know they are compiling for a particular target,
and some language frontends inject target-aware attributes early. These leaks are intentional. They let the optimizer
remain useful on real hardware without forcing every transformation to become target-specific.

7. Source Tour

The middle-end lives primarily in three places:

llvm/lib/Transforms/ — the transformations themselves (Scalar, Vectorize, IPO, Utils, \ldots)
llvm/lib/Analysis/ — analyses that transformations query (LoopInfo, AliasAnalysis, ScalarEvolution, \ldots)
llvm/lib/Passes/ — the New Pass Manager infrastructure and the pipelines that assemble analyses and transformations into -O2, -O3, etc.

Target queries surface through headers in llvm/include/llvm/Analysis/ (especially TargetTransformInfo) and are
implemented by each backend.

8. Looking Ahead

The middle-end can now improve IR without knowing the original language and without knowing most
micro-architectural details. The IR, however, still describes an ideal machine: infinite
registers, uniform instructions, and simple control flow.

Real processors have finite registers, various specific types and operations, complex
calling conventions, and idiosyncratic instruction encodings. The next engineering problem is
therefore:

How does LLVM turn ideal IR instructions into legal machine instructions for many different ISAs without forcing the middle-end to know about those ISAs?

That problem forces the introduction of instruction selection and Machine IR — the subject of Part 4.

Design Principle #3 — Optimize Against a Simplified Model

When many different hardware implementations must be supported, perform the bulk of optimization
against a simplified, mostly hardware-agnostic model, and consult detailed target information only
through narrow, explicit interfaces.

LLVM IR erases finite registers, pipeline structure, branch-predictor behavior, and most
memory-reordering details so that the same passes can serve many languages and many architectures.
The few facts that must be known are obtained through DataLayout, TTI, and TLI. Everything else is
deferred until the backend, where target-specific knowledge is unavoidable.

Series Thread

Every abstraction in LLVM exists because the previous one could not adequately contain a particular form of complexity.

The monolithic compiler could not solve the N × M problem → libraries (Part 1).
ASTs and assembly could not serve as a shared medium → LLVM IR (Part 2).
Language-specific or architecture-specific optimizers could not be reused → a middle-end that operates on a simplified, mostly target-independent model of the IR (Part 3).

The next abstraction will confront the fact that this simplified model must eventually be
reconciled with the chaotic reality of actual instruction sets.

Inside LLVM: Engineering a Target-Independent Compiler(2)

Reginald Ojunga — Fri, 14 Aug 2026 04:56:31 +0000

Part 2 — LLVM IR: Designing a Universal Contract
The Interface Between Languages and Machines

1. The Question

In Part 1 we established why LLVM was organized as a collection of reusable libraries.
The primary objective was to find a way to at least reduce the need to always reinvent the wheel.
A new language no longer needs to invent its own optimizer, and a new architecture no longer needs to reimplement an entire compiler.

That architecture, however, rests on a single, critical assumption:

The existence of a common representation that every frontend can produce and
that the shared optimizer and backends can consume.(so the IR is load bearing to its success)
In the absence of such a representation, the library boundaries described in
Part 1 would be meaningless. Each frontend would still be forced to speak a private language to the rest of the system.

The central question of this article is therefore:

How can Clang, Rust, Swift, Zig, and many other languages all feed the same optimizer?

The answer is LLVM IR — a carefully engineered software contract.

2. The Limitation

Two natural candidates already existed long before LLVM.

(a). Abstract Syntax Trees preserve almost everything a frontend knows about the source program:
syntactic structure, types, scopes, and language-specific semantics. They are excellent for language-specific
analysis and transformation. They are poor candidates for a shared abstraction.
Their use results to a fragile interface that proves constricting to language designers
(There are only so many language grammars a single AST can represent).

An AST for Rust's ownership and borrowing rules has little in common with an AST for C's
unchecked pointers or Swift's reference counting. An optimizer written against one would be
nearly useless for the others. The N × M problem would simply reappear at the level of tree walks and type checkers.

Consider:

int add_one(int x) {
    return x + 1;
}

At the source/AST level, the compiler still sees language concepts:

FunctionDecl
└── name: add_one
    return type: int
    parameter:
        └── x : int
    body:
        └── ReturnStmt
            └── BinaryOperator '+'
                ├── DeclRefExpr: x
                └── IntegerLiteral: 1

It knows that this is a C function, that x is an int, that + is a source-level
addition expression, and that the expression is the operand of a return.

Note: This example may not clearly illustrate the advantages of LLVM IR over ASTs
because of the stable way in which function structures are conceptualized across different
languages. But try thinking of language specific contexts. For instance, the various ways in which
object oriented languages model shared behavior. (Just pick a language specific context)

In contrast, LLVM IR:

define i32 @add_one(i32 %x) {
entry:
  %add = add i32 %x, 1
  ret i32 %add
}

There is no ReturnStmt, no BinaryOperator AST node, and no C-specific notion of an int declaration.
This means the constrain to neccessarily use the return keyword is lifted.(Of course, the space with
which one can describe what it means for a function to have a return value is limited but
at least it affords the authors a way to describe what it means for a function to have a return
value without being tied to a keyword or notation).

Programming languages are avenues to think about what is underneath.

The important point is not that LLVM IR contains less information. It contains different information: source-language structure has been replaced by explicit computation.

To further illustrate:

Consider a language level construct as:

fn increment(x: i32) -> i32 {
    x + 1
}

The Rust compiler can reason about properties that are meaningful at the Rust level:

Function
├── name: increment
├── parameter: x : i32
├── return type: i32
└── expression:
    └── Add
        ├── x
        └── integer literal 1

The AST can also retain language-specific information such as:

ownership
borrowing
lifetimes
generic parameters
traits
pattern matching
source locations
visibility
attributes

This is an oversimplified way of potraying rustc.

An optimization pass that has to generalise across mulitple target architectures has no need
to grasp the language-specific details of the source code.

(b). Raw assembly or machine code sits at the opposite extreme. It is already target-specific. Register names,
instruction encodings, calling conventions, and ABI details are baked in. An optimizer working at this level
cannot be shared across architectures, and many high-level opportunities (inlining across language boundaries,
high-level loop transformations, language-independent alias analysis) have already been lost.

What was missing was a representation that is:

low enough to model real computation efficiently,
high enough to support powerful, language-independent optimizations,
stable enough to serve as a long-lived interface between many independent projects.

Neither ASTs nor assembly satisfied that combination of requirements. A new abstraction was required¹.

3. Enter LLVM IR

LLVM IR is that abstraction.

It occupies the narrow design space between language-specific trees and machine-specific code.
Frontends lower their ASTs into LLVM IR; the middle-end optimizes that IR without knowing which
language produced it; backends later lower the optimized IR into Machine IR and ultimately machine
code.

Consider our initial function after lowering to a target architecture.

LLVM IR:

define i32 @add_one(i32 %x) {
entry:
  %add = add i32 %x, 1
  ret i32 %add
}

On an x86-64 System V target, the corresponding assembly can be as simple as:

add_one:
    lea     eax, [rdi + 1]
    ret

On AArch64:

add_one:
    add     w0, w0, #1
    ret

On RISC-V:

add_one:
    addi    a0, a0, 1
    ret

The important observation is that the LLVM IR is the same, while the machine instructions differ.

The conceptual stack is therefore:

Thus, LLVM IR is deliberately not a programming language in the conventional sense. It is a
contract that defines:

what values exist,
how control flows,
what operations are expressible,
and what properties the optimizer may rely upon.

Once a frontend has emitted valid LLVM IR, it has fulfilled its primary obligation to the rest of the infrastructure.

4. The IR structure

Before we get to describing the structure consider the following instance:

int abs_value(int x) {
    if (x < 0)
        return -x;
    return x;
}

The AST expresses the source structure:

Function
└── IfStmt
    ├── condition: x < 0
    ├── then:
    │   └── return -x
    └── else:
        └── return x

The LLVM IR representation of the abs_value function makes the control-flow structure explicit:

define i32 @abs_value(i32 %x) {
entry:
  %cmp = icmp slt i32 %x, 0
  br i1 %cmp, label %negative, label %positive

negative:
  %neg = sub i32 0, %x
  br label %done

positive:
  br label %done

done:
  %result = phi i32 [ %neg, %negative ], [ %x, %positive ]
  ret i32 %result
}

Now the optimizer can see an explicit control-flow graph:

The phi instruction is important here. It represents the SSA value selected
according to which predecessor block was taken. LLVM's language reference
specifies phi precisely in terms of the predecessor blocks of the current basic block.

This is something an optimizer benefits from having explicitly represented rather than having to
rediscover from source-level syntax.

The previous IR contains two control-flow paths.

But the optimizer may recognize that the computation can be expressed using a conditional move or equivalent target instruction.

Conceptually:

        x < 0 ?
       /       \
    -x           x
       \       /
          result

On x86-64, one possible optimized result is:

abs_value:
    mov     eax, edi
    neg     eax
    cmovns  eax, edi
    ret

So to further refine the nature of the pipeline, what we currently have is;

At the heart of the IR are a small number of interlocking concepts.

Values, Users, and Use-Def Chains

Every computed result is a Value. Every place that consumes a value is a User. The edges between them
form use-def and def-use chains. These chains are the primary data structure that almost every analysis and
transformation walks. Because the IR is in SSA² form, each value has a single definition, which
dramatically simplifies many algorithms.

Modules, Functions, Basic Blocks, and Instructions

A Module is the top-level container (roughly a translation unit). It contains Functions.
Each function contains BasicBlocks. Each basic block contains a linear sequence of
Instructions that ends in a terminator. This hierarchical structure gives optimizers clear units
of work and clear control-flow graphs.

The Type System

LLVM IR is strongly typed. Integer types of arbitrary bit width, floating-point types, pointers, arrays,
structs, vectors, and function types are all first-class. The type system is deliberately low-level;
it does not encode high-level language notions such as classes, ownership, or generics. Those concepts must
be lowered by the frontend.

DataLayout

While the IR tries to remain target-independent, the physical layout of data cannot be ignored. The DataLayout
string describes pointer sizes, alignment rules, endianness, and related properties. It is the first controlled leak
of target information into the "target-independent" IR.

Attributes, Metadata, and Calling Conventions

Function and parameter attributes, metadata nodes, and explicit calling-convention annotations provide the additional
channels through which frontends and targets communicate information that does not belong in the core instruction set
(inlining hints, aliasing properties, debug information, exception-handling tables, etc.).

Together these mechanisms form a complete, self-contained intermediate language that is stable enough to serve as a
binary interface (bitcode) and expressive enough for serious optimization.

5. Design Trade-offs

LLVM IR must satisfy two opposing pressures simultaneously.

It must be high enough that the same optimizer can improve code originating from very different languages.
High-level information that has been needlessly discarded cannot be recovered later.

It must be low enough that the eventual mapping to real hardware remains efficient. An IR that is too abstract
forces the backend to re-discover facts that should have been explicit.

The design therefore makes a series of deliberate choices:

SSA form is required. This simplifies optimization at the cost of making the IR harder to emit directly from some frontends.
The type system is structural and relatively simple. Rich language type systems must be erased or encoded explicitly by the frontend.
Control flow is explicit and unstructured (basic blocks + terminators) rather than structured. This makes many analyses uniform at the cost of losing surface syntax.
Side effects, memory, and concurrency are modeled with a relatively small set of primitive instructions plus attributes and metadata.

These decisions are not inevitable; they are engineering judgments about which complexities belong in the shared middle
and which complexities should be pushed into frontends or backends.

6. The Abstraction Leaks

Even though LLVM IR is presented as target-independent, several forms of target knowledge already appear inside it:

DataLayout — pointer size, ABI alignment, endianness.
Target Triple — identifies the intended architecture, vendor, and operating system.
Calling conventions — encoded as attributes because different platforms pass arguments differently.
Address spaces — required for some architectures and for certain language features (e.g., GPU memory spaces).
Atomic memory operations — whose precise semantics can depend on the target’s memory model.

These are not accidental impurities. They exist because a purely target-agnostic IR would force either incorrect code or
an explosion of complexity in every backend. LLVM’s pragmatic stance is that a small, well-documented set of target facts
may appear early, provided the great majority of optimization remains independent of any particular ISA.

The presence of these leaks reinforces a principle already stated in Part 1: good abstractions isolate complexity; they
do not pretend the complexity has vanished.

7. Source Tour

The core IR implementation lives in two tightly related locations:

llvm/include/llvm/IR/ — public headers defining Module, Function, BasicBlock, Instruction, Value, Type, DataLayout, attributes, metadata, and related classes.
llvm/lib/IR/ — the corresponding implementations, including the bitcode reader/writer, the assembler/disassembler for the textual IR, and the core data structures that maintain use-def chains.

When reading this code, notice how little of it knows about any particular programming language or processor.

8. Looking Ahead

We now have a common language that many frontends can speak and that a shared optimizer can understand. The next engineering question
is immediate:

Once a program has been expressed in LLVM IR, how should a collection of independent analyses and transformations be organized so
that they remain composable, reusable, and largely target-independent?

That question leads directly to the Pass Manager and the middle-end contract — the subject of Part 3.

Design Principle #2 — Define a Stable Intermediate Contract

When many independent producers and consumers must cooperate, introduce a narrow, well-specified intermediate representation
that both sides can rely upon.
ASTs were too language-specific. Assembly was too machine-specific. LLVM IR was introduced to occupy the space between them and thereby make the library-based architecture of Part 1 possible. Every later abstraction in LLVM builds on the existence of this contract.

Series Thread

As previously stated or at least hinted at, every abstraction in LLVM exists because the previous one could not adequately contain
a particular form of complexity.
The traditional monolithic compiler could not solve the N × M scaling problem → LLVM introduced the compiler-as-libraries abstraction (Part 1).
ASTs and assembly could not serve as a shared medium between many languages and many targets → LLVM introduced LLVM IR as the universal
contract (Part 2).

The next layer will confront a new problem: how to organize dozens of independent optimizations so that they remain maintainable and reusable across all the languages that now speak this common IR.

More information can be found from Lattner's thesis and the LLVM documentation. ↩
SSABook ↩

Inside LLVM: Engineering a Target-Independent Compiler(1)

Reginald Ojunga — Tue, 11 Aug 2026 05:13:43 +0000

Why LLVM Exists

From Many Compilers to One Infrastructure

1. The Question

Imagine it is the late 1990s. You form part of a team that has built a successful compiler for a
single programming language targeting a single processor architecture. The system is well
understood, the optimizer is producing good code, and the backend reliably emits binaries
for your target machine.

Then the requirements change.

A second programming language needs to be supported. Soon after, a new processor architecture becomes
commercially important. Before long, customers expect support for multiple languages, multiple operating
systems, and an ever-growing range of processor families.

You get in the business of supporting infrastructure.

At this point, the problem is no longer writing a compiler. The problem is maintaining an ecosystem of compilers
that all need the same optimizations, the same bug fixes, and the same engineering improvements.

Is it possible to have a compiler infrastructure that supports dozens of programming languages and dozens of processor architectures?
How will it tame such complexity?

Before we examine any data structure, optimization pass, or backend interface, it makes sense to understand the engineering
problem that forced LLVM into existence.
Modern LLVM is best understood as a response to a scaling problem that
traditional compiler architectures could not solve.

2. The Limitation

A traditional compiler is often presented as a simple linear pipeline.

For a compiler supporting one language and one architecture, this design works remarkably well. Every phase
is built specifically for that single combination, allowing the implementation to be tightly integrated.
The difficulties begin when either side of the pipeline grows.
Suppose we wish to support five programming languages targeting three processor architectures.


Languages                  
|---C                         Targets
|---C++                        
|---Rust               x86       ARM      RISC-V
|---Swift                |________|_________|
|---Zig              

5 Languages × 3 Architectures = 15 compiler combinations

Without a shared infrastructure, every combination requires its own compilation pipeline.
If more languages and architectures are added, the amount of duplicated engineering effort
grows rapidly.

This phenomenon is commonly known as the N × M problem.

The difficulty extends far beyond parsing source code or generating machine instructions.
Every compiler benefits from sophisticated analyses and optimizations: dead code elimination,
loop optimizations, common subexpression elimination, function inlining, register allocation,
instruction scheduling, and many others.

In a traditional architecture, improvements to these algorithms often had to be implemented repeatedly
across multiple compiler implementations. The same optimization might exist in several slightly different
forms, each evolving independently, each accumulating its own bugs and maintenance costs.

The traditional architecture therefore suffered from two fundamental scaling problems:

The N × M problem — every new frontend or backend increases the number of compiler combinations that must be maintained.
A non-reusable middle — the most sophisticated and valuable parts of a compiler, namely its analyses and optimizations, could not easily be shared across languages or architectures.

As software development expanded beyond a handful of languages and processor families,
these problems became increasingly expensive. The challenge was no longer writing compilers
— it was preventing compiler engineering effort from growing exponentially.

3. The New Abstraction

While LLVM IR is a critical component of the infrastructure, I would argue that
LLVM's most significant innovation was not the IR¹.

Its most significant innovation was architectural.

Rather than treating a compiler as a single executable that performs every stage internally, LLVM treats a compiler as a collection of reusable libraries.

The resulting architecture appears deceptively simple:

The frontend becomes responsible for understanding a programming language and translating it into LLVM IR.
The middle-end performs analyses and optimizations without needing to know which language produced the IR.
The backend translates that optimized IR into machine code for a specific processor architecture.

A new language no longer needs to build its own optimizer.
A new processor architecture no longer needs to implement an entire compiler.
Instead, both become clients of a common infrastructure.

It is important to understand what LLVM does not solve.

LLVM does not eliminate the complexity of supporting multiple languages or multiple architectures.
A frontend must still understand the syntax and semantics of its source language, and every backend
must still understand the instruction set, calling conventions, and ABI of its target processor.

What LLVM eliminates is the repeated implementation of everything that lies between those two ends.

The optimizer, analyses, large portions of the code-generation pipeline, and numerous supporting libraries become shared infrastructure rather than duplicated engineering effort.

This is the first and most fundamental abstraction in LLVM:

The compiler is no longer a monolithic program. It is a collection of reusable components connected through carefully designed interfaces.

4. How It Works

LLVM's architecture is reflected directly in the structure of the project itself.

At the top level of the repository are independent components rather than a single "compiler" directory.

llvm/ — the reusable core libraries, including LLVM IR, analyses, transformations, code generation, target descriptions,
the MC layer, and TableGen.
clang/ — one frontend among many.
lld/ — the linker.
compiler-rt/ — runtime support libraries required by generated programs.
libcxx/, libcxxabi/, and related projects — the C++ standard library implementation and supporting runtime components.

This organization reflects LLVM's philosophy.
The optimizer is not owned by Clang.
The backend is not owned by Clang.
The IR is not owned by Clang.
Instead, Clang is itself a client of LLVM's libraries, just as a JIT compiler, a static compiler, a binary translator,
or a research tool can be.

The pipeline shown earlier therefore represents more than compilation stages.

Each boundary represents a library interface designed to isolate one class of variation from another.

5. Why These Boundaries Exist

A recurring theme throughout this series is that LLVM introduces a new abstraction only when an existing one can no longer contain complexity.

Programming languages evolve independently from processor architectures.

A language designer may introduce new type systems, ownership models, generics, or concurrency features without changing anything about modern CPUs.

Likewise, processor architects continue to develop wider vector units, new instruction sets, and increasingly sophisticated microarchitectures without any knowledge of Rust, Swift, or C++.

LLVM deliberately separates these two axes of variation.

The boundary between the frontend and the optimizer isolates language-specific complexity.

The boundary between the optimizer and the backend isolates hardware-specific complexity.

Rather than allowing these differences to permeate the entire compiler, LLVM confines each category of variation behind a dedicated interface.

Every major abstraction introduced later in this series follows exactly the same design philosophy.

6. Design Trade-offs

Library boundaries are not free.

Every reusable interface must be expressive enough to satisfy many clients without becoming so general that meaningful optimization becomes impossible.

LLVM IR must simultaneously support Clang, Rust, Swift, Julia, Zig, and many other frontends while remaining suitable for aggressive optimization.

Likewise, backend interfaces must describe processors ranging from small embedded microcontrollers to large server CPUs and GPUs.

Designing these interfaces therefore becomes an exercise in balance.

Interfaces that are too narrow cannot accommodate new languages or architectures.

Interfaces that are too broad lose precision and become increasingly difficult to optimize effectively.

Much of LLVM's evolution can be understood as the continuous refinement of these interfaces.

The project deliberately accepts additional compile-time complexity and larger libraries in exchange for dramatically lower long-term engineering cost and substantially greater code reuse.

7. The Abstraction Leaks

Even at this highest level the abstraction is imperfect.

Target independence is an objective rather than an absolute guarantee.

Certain information about the target machine must already be available while LLVM IR is being generated. Calling conventions, data layouts, pointer sizes, address spaces, and other architectural properties influence the correctness of generated programs.

Consequently, LLVM provides carefully controlled mechanisms through which target-specific knowledge flows into otherwise target-independent components.

These leaks are not failures of the design.

They are examples of a recurring engineering principle that appears throughout LLVM:

Good abstractions isolate complexity; they do not pretend that complexity no longer exists.

8. Source Tour

The top-level structure of the LLVM project already reveals its architectural philosophy.

llvm/ — reusable compiler infrastructure.
clang/ — one frontend built on that infrastructure.
lld/ — the linker.
compiler-rt/ — runtime libraries.
libcxx/ and related projects — standard library components.

Notice what is absent.

There is no directory that simply contains "the compiler."

Instead, there is a collection of interoperable components that can be assembled in different ways depending on the needs of the tool being built.

9. Looking Ahead

We now understand why LLVM was organized as a collection of reusable libraries.

That naturally leads to a deeper question.

If dozens of programming languages are expected to share a single optimizer, what common language do they all speak?

The answer is LLVM IR.

Far more than an intermediate representation, LLVM IR is the central contract around which the entire LLVM ecosystem is built. It is expressive enough to represent a wide variety of source languages, yet constrained enough to enable powerful, target-independent optimizations.

In Part 2, we will examine why abstract syntax trees are insufficient, why raw assembly is insufficient, and how LLVM IR was engineered to occupy the narrow but crucial space between them.

Design Principle #1 — Isolate variations

When different parts of a system evolve for different reasons, separate them behind a stable interface.²

Programming languages and processor architectures evolve independently. LLVM's first architectural decision was to isolate those two axes of change so that new languages and new targets could reuse the same optimization and code-generation infrastructure. Every major abstraction introduced later in LLVM is an extension of this same principle.

Series Thread

Every abstraction in LLVM exists because the previous one could not adequately contain a particular form of complexity.

The traditional monolithic compiler could not solve the N × M scaling problem. LLVM's first abstraction—treating the compiler as a collection of reusable libraries—was introduced to solve exactly that problem. Every subsequent layer in the series will reveal another engineering challenge, another abstraction, and another carefully chosen boundary.

Joran Dirk Greef may disagree with me on this. ↩
One thing that is observable in hardware/sotware interface, any time one encounters a relatively radical idea, chances are a new functional unit is involved. ↩