perf(parser): table-driven operator precedence lookup

[Boshen]

kind_to_precedence is called for every token while parsing binary expressions; replace the branchy match with a 256-entry lookup table indexed by Kind discriminant.

Interleaved A/B benchmark (12 alternating runs, medians) showed ~-1.3% on binder.ts from this change alone. Conformance and snapshots unchanged.

🤖 Generated with Claude Code

[codspeed-hq]

Merging this PR will not alter performance

✅ 62 untouched benchmarks
⏩ 9 skipped benchmarks¹

---

_{Comparing perf/parser-precedence-table (ad1844b) with main (6e516f7)}

Footnotes

1. 9 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[Boshen]

Merge activity

• Jun 12, 2:28 PM UTC: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• Jun 12, 2:28 PM UTC: Boshen added this pull request to the Graphite merge queue.
• Jun 12, 2:36 PM UTC: Merged by the Graphite merge queue.

[Boshen]

Comparing the generated assembly (aarch64, release) of the table version vs the original match:

Table — 4 instructions, zero branches:

and   x8, x0, #0xff          ; kind as usize
adrp  x9, PRECEDENCE_TABLE@PAGE
add   x9, x9, ...@PAGEOFF
ldrb  w0, [x9, x8]           ; one byte load
ret

Original match — LLVM already lowers it to a jump table, but a heavier one:

and   w8, w0, #0xff
mov   w0, #23                ; preload None
sub   w8, w8, #25            ; range check
cmp   w8, #119
b.hi  default                ; branch 1
adrp  x9, LJTI...
ldrb  w11, [x9, x8]
add   x10, x10, x11, lsl #2
br    x10                    ; branch 2 (indirect)
mov   w0, #13                ; one of ~12 mov/ret blocks
ret

Both are table-driven, but the match's table holds code offsets requiring an indirect br into ~12 separate mov/ret blocks, while the new table holds the answers directly. Token sequences are effectively random to the branch predictor, so that indirect branch mispredicts frequently in the hot binary-expression loop; the data table is a single branchless byte load (256 bytes = 4 cache lines, stays L1-hot). That's where the ~1.3% comes from.

Caveat: native-only. On wasm both versions compile to roughly equivalent br_table constructs (wasm binary delta is +44 bytes), so the gain there is likely much smaller.