perf(vm): numeric fast path for comparisons + integer % [1/4 of #39]

[mparrett]

Part 1 of the #39 split.

Collapses the per-opcode number guards into one fast path shared by all 13 arithmetic and comparison opcodes, reading the type tags directly rather than through ToFloat() (too large to inline). Comparisons previously had no fast path at all and paid the full ToPrimitive/helperCallDepth/unwinding bookkeeping on every loop condition.

Semantics. ToPrimitive is the identity on numbers, so the fast path computes what the general path would. NaN needs no special casing: Go's float comparisons are already false in all four relational directions, and l == r is false for NaN, matching StrictlyEquals. For two numbers abstract and strict equality coincide, so OpEqual/OpStrictEqual share an arm.

Integer %. math.Mod is a software frexp/ldexp loop, ~7% of the recursion benchmark's profile. Go's truncated int64 remainder takes the dividend's sign, exactly matching JS, so the integer path is used only when both operands round-trip exactly through int64 (±2^53), the divisor is nonzero, and the result isn't a signed zero — JS requires -0 for a negative dividend with zero remainder, which the integer path would lose. Everything else falls through to math.Mod. tests/scripts/remainder_semantics.ts pins these, including 1 / (-7 % 7) === -Infinity.

The third commit drops the per-op number guards that the unified path made unreachable — the cleanup nit from your review.

The inner switch carries a default arm that degrades to the general path. It's unreachable today (the enclosing case list and the switch cover the same 13 opcodes), but without it, adding an opcode to that list without a fast-path arm would continue with destReg never written — a silently stale register, which is a worse failure than the slow path.

Where this sits in the #39 split

#39 bundled ~6 changes; per review it's split into four independent PRs, all branched off current main:

	branch	contents
1	perf/vm-numeric-compare-rem	comparison fast path, integer %, drop unreachable per-op guards
2	perf/vm-finally-nonalloc	non-allocating finally-handler check
3	perf/vm-dispatch-deadcode	dead debug blocks, redundant IsNaN cleanup
4	perf/vm-array-index-accessor-atomic	arrayIndexAccessorSeen → atomic.Bool

The other three pieces you flagged as unmentioned — the IsObject() range check, the ToInteger() fast path, and the arrayIndexAccessorSeen latch itself — already landed on main separately, so they aren't repeated here. Together these four are the remainder of #39.

The four merge onto main in sequence with no conflicts; the union passes TestScripts, pkg/vm, pkg/compiler, and go test -race ./pkg/vm/.

🤖 Generated with Claude Code

[mparrett]

Measured on a dedicated c7a.2xlarge (EPYC 9R14), go1.26.0, against the shared merge base 3167412e85c2. Targeted A/B: alternating launches, b.N pinned at 8, median of 5–8 launches per arm. Negative is faster.

benchmark	Δ
FibPlaceholderRun	−23.5%
Arith	−21.5%
MatrixMult	−19.8%
Add	−18.8%
SetIndex	−4.0%

This is the one clear win of the six open perf PRs. The pattern is coherent with what the change claims: the four numeric-heavy workloads all move together by roughly a fifth, while SetIndex — array writes rather than arithmetic — barely moves. That internal contrast is most of why I believe it.

One caveat in your favour: the four-round session run understated this at −13 to −18%, because the calibration anchor took a ~4% transient excursion during two of this commit's four rounds and normalising by it ate part of the win. The targeted A/B above avoids that.

Floors from null controls in the same run: two commits compiling to byte-identical binaries measure up to 3.7% apart on ./tests. A layout control (real code added, never executed) is no worse — so anything under ~4% here is not attributable to the change. Full write-up and raw data: perf-session-remeasure-results.md.