Optimise machine code where reordering survives

[AndreSlavescu]

meTile's IR scheduler is measured to be inert — Apple's backend rebuilds the schedule from the
dataflow, so two source orders compile to byte-identical instructions. That's not a shortcoming of
the pass; it's where the boundary of control sits when the output is MSL. This pass is on the
other side of it: it reads the instructions the backend produced, rewrites them, and puts them
back, so nothing downstream re-derives anything.

Why it's possible now

The register field. A compact fma names its register in byte 0's high nibble and again as
(r << 1) | 1 in byte 1, so which instructions depend on each other is readable rather than
guessed. This form reads and writes exactly one register, so two fmas on different registers are
independent and two on the same one are not — that is the entire dependence relation.

pass	what it does
simplify	retires instructions computing nothing, via the flag verified indistinguishable from nopping
reorder	moves independent instructions, preserving every register dependence

Both bit-exact by construction, and checked that way rather than argued. On three chains over
three registers, reordering moves 7 of 8 instructions and the GPU returns the same three values;
retiring a planted identity changes nothing either. An unsound rewrite here produces a kernel that
compiles, dispatches, and returns a wrong number — a structural check would not catch it.

The one job this level cannot finish

Worth naming rather than omitting. Splitting a dependent chain across registers is within reach —
the register field is known, half a chain can be retargeted — but the two partial results then need
adding together, and a register-plus-register add is not among the decoded forms; every operand
slot mapped so far takes an immediate. Half a transformation leaves a kernel computing half an
answer. So the ILP half stays in metile.compiler.scheduling at the IR level, where reassociation
needs no new instruction, and optimize is the one entry point naming both.

Two things the tests caught in my own code

1. is_identity checked for a * 1 + 0, which cannot exist: the immediate field holds
   (1 + m/8) · 2^(e−11), smallest value 2^−11, so there is no encoding for zero and a decoded
   addend is never it. The branch was unreachable.
2. The run-continuation bit is positional, not a property of the operation, so moving an
   instruction to or from the end of a run has to recompute it.

Scope enforces itself

Only the compact f32 fma is decoded, and any byte that is not part of a decoded instruction is a
barrier. Not caution for its own sake — instruction lengths cannot be recovered in general, since
the length-field theory failed on 8 of 8 kernels, so an undecoded region might be one instruction
or twenty.

9 tests, 646 in total. Lint clean.

🤖 Generated with Claude Code