Poking holes into bytecode with peephole optimisations(xnacly.me)
xnacly.me
Poking holes into bytecode with peephole optimisations
https://xnacly.me/posts/2026/purple-garden-first-optimisations/
8 comments
I like that you are treating peephole as a strict fallback after IR optimizations, with a tiny window and single pass. In a lot of compilers this stage turns into a junk drawer of pattern matches that quietly grow until no one remembers why half of them exist.
The opt_trace! hook is the underrated bit here. Once you start rewriting instruction sequences, knowing which patterns fire and how often on real programs is usually more valuable than another synthetic benchmark. Keeping it behind -O1 is a nice way to make sure you only pay for that complexity when users actually opt in.
The opt_trace! hook is the underrated bit here. Once you start rewriting instruction sequences, knowing which patterns fire and how often on real programs is usually more valuable than another synthetic benchmark. Keeping it behind -O1 is a nice way to make sure you only pay for that complexity when users actually opt in.
Does it make sense to implement constant folding using peepholes for an ISA like this (with plenty of registers and limited scope for immediate operands)?
I would expect the constant loads to float away from their use sites, so that more instructions can use them. For example, 0 or 1 might be loaded at the start of the function.
I would expect the constant loads to float away from their use sites, so that more instructions can use them. For example, 0 or 1 might be loaded at the start of the function.
The example: 2+3*4-1 should resolve to either LR: 19 RL: -7 PEMDAS: 13
and never this: 15
Who would expect a language where add/sub is more tightly binding than mul? Its feels akin to starting your indexes at 2, it's not illegal, if you remember everything works, but its a true foot gun in a scripting lang.