- Author
- Henrique Cabral
- Published
- 20 March 2026
- Kind
- Personal blog post with annotated compiler output and exercises
- Original
- www.hmpcabral.com/2026/03/20/two-studies-in-compiler-optimisations/
- Subject
- Compilers and interpreters
- Themes
- Close to the machine, Getting good
What it is
Henrique Cabral wrote a blog post that explains LLVM internals through two examples. One is a modular increment for round-robin indexing. The other is converting bytes to an integer with a chosen byte order. The aim is to show how small source changes change the compiler path.
What it says
- The InstCombine pass turns (cur + 1) % count into a compare and conditional move. It does so when cur < count is provable.
- An assume attribute or an enabled assert can supply that fact. The post notes builds with assertions can run faster.
- In a loop, the division stays unless count is known to be nonzero. An early return for zero fixes it.
- If the loop computes i % count directly, a different pass, CodeGenPrepare, does the replacement.
- A generic loop that joins bytes is folded into one load only at instruction selection.
- Making the loader a template lets an earlier pass, AggressiveInstCombine, fold little-endian loads.
- A wrapper that also reads data[0] defeats the byte-load folding. The post explains why.
What evidence it gives
The post shows assembly output for each variant, intermediate-code diffs, and excerpts from LLVM source. It names the pass behind each change. It gives no timing benchmarks. Its one cost figure is a division latency on one Intel core.
Interests and limits
The author is an independent blogger with no stated commercial interest. All results use one LLVM version, 22.1.0, on x86-64. Other compilers are only mentioned, and gcc is said not to fold the loads. Behaviour in other versions and targets was not tested. The conclusions are advice, not measured speed-ups.