feat: add a whole-program optimizing compiler section to the front page - #223
Merged
Conversation
Adds a section to the front page covering what the compiler does to the code it generates: monomorphization, inlining, dead code elimination, compile-time pattern matching, lambda dropping, tree shaking, and tail call elimination. It sits after "Compiler Performance: The Raw Numbers" so the compiler region reads architecture -> compiler speed -> generated-code quality. That section already claims the compiler is fast "despite supporting costly features, including monomorphization and whole-program optimization" without ever saying what those are; this explains them. Each bullet leads with the technical name but explains it in terms of the code the reader writes rather than the transformation the compiler performs. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Seven bullets at full width made a tall, thin block quite unlike the three-column Complete Feature List above it. Splits them across two col-md-6 columns, following the row structure that section already uses: the heading and lead span col-md-12, the lists sit in sibling columns, and the closing paragraph spans the full width again. Split 3+4 rather than 4+3. The first three bullets carry about half the text between them, so an even count would leave the left column noticeably longer; reading order down the left and then the right is the same either way. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Replaces the seven prose bullets with a worked example and the bytecode
the compiler actually emits for it. A polymorphic, higher-order fold over
a mutable array in a region compiles to a 34-byte counted loop over a
bare int[], with the lambda reduced to a single imul.
Every claim beside the listing was verified against a real build with
flix 0.75.2:
- no Clo$main$* class is emitted, so neither sumWith nor the lambda
survives as a closure;
- the loop body's entire opcode inventory is loads, stores, arithmetic
and branches -- no invoke, new, or newarray;
- the array is allocated once in main, outside the loop.
The listing elides only the trailing boxing of the result. The loop body
has no constant-pool references at all, so it is otherwise verbatim
javap output plus comments.
Retitles the section to name whole-program optimization, which the
performance section directly above already claims without explaining,
and drops the reference to JVM bytecode from the lead in favour of the
optimizations themselves.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
magnus-madsen
marked this pull request as ready for review
August 10, 2026 13:30
"Write code in whatever style you prefer" is a broad promise, and the four bullets beside it are each carefully scoped to one worked example. Marks the claim with an asterisk and answers it below the bullets, in the same muted style as the reproduce note in the opposite column. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds a section to the front page showing what the compiler does to the code it generates — built around a worked example and the bytecode actually emitted for it, rather than a list of claims.
The figure
A polymorphic, higher-order fold over a mutable array in a region compiles to a 34-byte counted loop taking a bare
int[]and three rawints, with the lambda reduced to a singleimuland the recursion togoto 0.Every claim beside the listing was verified against a real build with
flix0.75.2:Clo$main$*class is emitted at all, so neithersumWithnor the lambda survives as a closure.Array.foldLeftis recursive; the emitted code ends ingoto 0.(int[], int, int, int); only the final result is boxed.invoke,new, ornewarray.The listing elides only the trailing boxing of the result. The loop body has no constant-pool references at all, so it is otherwise verbatim
javapoutput plus comments, reproducible withflix buildfollowed byjavap -c -p.Placement and framing
It sits after "Compiler Performance: The Raw Numbers", so the compiler region reads architecture → compiler speed → generated-code quality. That section already claims the compiler is fast "despite supporting costly features, including monomorphization and whole-program optimization" without ever saying what those are; the new section's title and lead now name them.
How the example was chosen
Three variants were built and disassembled before settling on the region-based one:
List(int, Tagged$)Vector(int, int, int)newarrayevery iterationArray(int[], int, int, int)The region version wins on every axis, and earns a claim the others can't: the region has no runtime representation in the loop —
mainallocates aRegion$, but the loop receives a plain array.