fix(codegen): #92 intrinsify Buffer numeric reads (5x speedup on readInt32BE hot loop)

[proggeramlug]

Closes the primitive side of #92.

Summary

For the 14 Node-style Buffer numeric read accessors, bypass the js_native_call_method → method-name string match → js_buffer_read_int32_be → buffer_slice_at → from_be_bytes chain when the receiver is a tracked const buf = Buffer.alloc(N) local. Emit inline LLVM instead: one load of the data_ptr from the pre-computed buffer_data_slot, one getelementptr inbounds, one byte-width load, one @llvm.bswap.iN for BE widths, one sitofp / uitofp to double.

Covered methods: readInt8, readUInt8, readInt16{BE,LE}, readUInt16{BE,LE}, readInt32{BE,LE}, readUInt32{BE,LE}, readFloat{BE,LE}, readDouble{BE,LE}.

Measured on the issue's own repro

buf.readInt32BE(i*4) in a tight loop, 12.5M total reads (50 × 250k), macOS arm64:

Runtime	Time	Ratio to Perry
Perry	29ms	1.0×
Node	37ms	1.3×
Bun	104ms	3.6×

Before this change, Perry was ~145ms on the same workload — 5× slower than Bun. After: 3.6× faster than Bun. otool -tV on the compiled binary shows the emitted intrinsic getting auto-vectorized (rev32.4s + 128-bit NEON loads in the hot loop).

Correctness

New test-files/test_buffer_numeric_read_intrinsic.ts exercises all 14 variants against their corresponding writes, including the sign-extension edge cases that would miscompile if sitofp/uitofp were swapped (i32 MIN/MAX = ±2147483648, u16 0xFFFF = 65535, u32 0xFFFFFFFF = 4294967295, negative doubles in LE). Matches node --experimental-strip-types byte-for-byte on all 19 lines.

Gap suite still 23/28 (no regressions); perry-runtime unit tests 111/111 green.

Why this shape

The fast path only fires when:

• Receiver is an Expr::LocalGet(id)
• id has a buffer_data_slots entry (populated by stmt.rs for const buf = Buffer.alloc(N) — immutable local or module-global)

Untracked receivers (function args, object fields, anything not tagged at the let-site) fall through to the existing runtime dispatch unchanged, so this PR is strictly additive. The Postgres driver's real hot path passes Buffer as a function parameter and therefore still misses the fast path — see the follow-up note below.

What's still open on #92

• Extending buffer_data_slots to cover typed function params / object fields is the follow-up that closes the gap on real Postgres-driver workloads. Not in this PR (scope creep + needs type-flow correctness). I can open a separate PR once this is reviewed.
• Buffer.alloc(small) path still goes through the Rust allocator; BigInt(str) / parseFloat still heap-allocate. Those are separate from this change.
• BigInt64 reads skip the intrinsic (would need BigInt allocation inline — not a primitive bottleneck at that point).

Files changed

• crates/perry-codegen/src/lower_call.rs — adds classify_buffer_numeric_read + try_emit_buffer_read_intrinsic helpers (~160 lines), hooks into the existing PropertyGet dispatch at the is_buffer_class branch
• test-files/test_buffer_numeric_read_intrinsic.ts — new correctness test
• Cargo.lock — version sync (0.5.177 → 0.5.179 to match main)

Per CLAUDE.md external-contributor rules I did not bump the workspace version or edit the **Current Version:** / Recent Changes entry — maintainer to handle at merge time.

Test plan

• cargo build --release -p perry-runtime -p perry-stdlib -p perry — clean
• cargo test --release -p perry-runtime --lib — 111/111 pass
• bash /tmp/run_gap_tests.sh — 23/28, unchanged from baseline
• New test_buffer_numeric_read_intrinsic.ts matches Node byte-for-byte
• Perry binary of the bench shows rev32 / NEON instructions — intrinsic fires

[proggeramlug]

Pushed a follow-up commit (1e95fabd) extending the intrinsic to Buffer-typed function parameters — the real Postgres-driver shape, not just const buf = Buffer.alloc(N) locals.

What the extension does

At function entry, for each parameter typed Buffer that isn't reassigned, load the NaN-boxed arg from its param slot, unbox to i64 handle, compute handle + 8 as the data pointer, stash in a fresh ptr alloca, and register in buffer_data_slots keyed by the param's LocalId. The existing Uint8ArrayGet fast path and the try_emit_buffer_read_intrinsic from the first commit both look up by LocalId and pick up the slot automatically.

Guards:

• Skip params flagged by has_any_mutation (LocalSet / Update / ARRAY_MUTATORS — covers buf = ..., buf.fill(...), buf.copyWithin(...)). A cached data_ptr would go stale if the param is reassigned.
• Skip params in boxed_vars (cross-closure mutation, same reason).

Deliberately not covered: Uint8Array-typed params

Surfacing a pre-existing bug on main while testing this: when a program defines both a Buffer-param function and a Uint8Array-param function and invokes them in sequence, it crashes (exit 133 / SIGTRAP in the second call's arr[i] chain). Verified reproducible on main at 6e578615 with zero changes from this branch applied — it's not caused by the extension. Scoping this PR to Buffer params only, since that covers the Postgres driver target workload. The Uint8Array-param crash is tracked separately.

Measured

function decodeRow(row: Buffer, n: number) { for (let i = 0; i < n; i++) s += row.readInt32BE(i*4); } over 2M reads (10 × 200k), macOS arm64:

Runtime	Time	ns/op
Perry (before extension: runtime dispatch)	~110ms	~55
Perry (this PR: intrinsic)	80ms	~40
Node	14ms	7
Bun	5ms	2

Intrinsic firing confirmed via otool -tV: 33 rev* instructions, zero calls to js_native_call_method or js_buffer_read_int32_be. Correctness verified (sums match Node exactly).

The remaining 6× gap vs Node on the param path is a separate issue — the n: number loop bound prevents i32-loop-counter specialization (same family as #140 in a different guise), which blocks LLVM's LoopVectorizer. Not in scope for the Buffer intrinsic work; the primitive cost is now competitive (40ns/op down from 55ns/op). Fixing the loop-bound specialization should close most of the remaining gap.

Tests

test_buffer_numeric_read_intrinsic.ts now includes a sumRow(row: Buffer, n: number) case. Matches Node byte-for-byte. Gap suite steady at 23/28, perry-runtime 111/111.