Compiler internals
These pages describe what the compiler does when you write ordinary Axle code — the analyses it runs, the rewrites it applies, and the LLVM IR shape it picks. Nothing here changes the language you write; it explains the machinery behind the guarantees the user-facing chapters mention.
You don’t need to read this section to write Axle programs. It’s
here for the curious — readers who want to know why a
particular allocation went to the stack, or how a hot loop
collapsed into a single memcpy.
Pages
The optimisations that don’t belong to a single user-facing theme live here:
| Page | What it covers |
|---|---|
| Loop and idiom rewrites | memset / memcpy recognition, monotonic-break collapse, loop-invariant hoisting, bounds-check & nullable elision by value-range, common-subexpression elimination, abs idiom, arithmetic peepholes, dead-code elimination, and the pointer to auto-vectorisation |
| Inlining and tail calls | When the compiler inlines a body, when self-tail-recursion becomes a loop, when it stamps the LLVM tail qualifier |
| Runtime and stdlib inlining | Why the stdlib and the hot runtime leaves inline into your module — the IR merge (one optimizer pass, not ThinLTO) and the available_externally leaf folding at -O≥2 |
The theme-specific internals
The remaining compiler-internal pages live next to the user-facing chapter they back:
| Internal page | Lives under |
|---|---|
| Escape analysis and promotion | Memory and ownership |
| Refcount and transitions | Memory and ownership |
| Exception dispatch | Errors and exceptions |
| SIMD CPU dispatch | Vectorisation |
How to read these
Each page starts with the user-visible behaviour (”new T(...) that doesn’t escape becomes a stack allocation”), then explains
the analysis or rewrite that produces it. None of them is a
prerequisite for writing Axle — but reading them tells you what
to expect in the generated code, and why two equivalent-looking
programs sometimes optimise very differently.
See also
- Optimisations — the user-facing map of what the compiler optimises, with the honest list of what it can and cannot prove.
- Memory model — the user-facing tier rules that escape analysis enforces.
Shared<T>reference counting — the user-facing surface of the refcount machinery.- SIMD and auto-vectorisation — the user-facing surface of the CPU-dispatch machinery.
- Reading compiler errors — what the analyses report when they reject a program.
- Concept index — every concept on one page with a link to where it’s documented.