[mparrett]

Closes #1055, the array half of #358.

A numeric kernel written the Clojure way, double-array plus ^doubles plus aget/aset, lowered to Go that boxed the index on every access, got the element back boxed, and so ran its whole accumulator chain on rt.AddValue. The runtime already held the element type (vm.TypedArray is a kind plus a native slice); nothing in the lattice or the lowerer could see it. This gives the lattice an array kind and the lowerer a use for it.

What changes

• Lattice: [:array K] for K in :byte :int :float :object, mirroring vm.ArrayKind. Non-maskable, joins like :dtype. The kind is declared, never inferred from elements: typeinfer types the six array constructors (long-array and float-array alias the 64-bit kinds they construct), and aget as the element type, alength as :int, aset as its value, aclone as its argument.
• Hints: ^doubles, ^floats, ^longs, ^ints, ^bytes, ^objects on params, next to ^double/^long in build.lg. The "unsupported hint" warning names them.
• Go type: every array kind lowers to *vm.TypedArray. It implements vm.Value, so a local boxes by interface conversion and the same backing store is shared with any un-lowered code that holds the array.
• Accessors on vm.TypedArray: AtFloat64/SetFloat64, AtInt64/ SetInt64, AtByte/SetByte, AtValue/SetValue, each one unsigned bounds compare and the access, with the kind check folded in (a wrong kind finds a nil field) and all error construction in a cold path, so each inlines (cost under 80). To get there the struct keeps one typed slice per kind instead of data any; Unbox() still returns the active slice.
• Lowering: aget/aset/alength on a proven array kind with a native int index emit the accessor, if rt.NativePrimsIntact() { typed } else { trampoline } like the other native primitives. An int value into a double-array widens, as TypedArray.Set coerces. Anything that does not line up (unknown kind, boxed index, nested aget) falls through to today's path.
• Calls into a *vm.TypedArray param: the Go spec does not carry the kind, so direct-call registry entries now carry :param-types (lattice) beside :param-specs. A proven array of the same kind passes through; a different kind, or a proven non-array, bails the call to the trampoline, which is what bytecode does (the hint is ignored there and aget works on any array); an unproven vm.Value gets the scalar guard's shape with && tg.Kind() == vm.ArrayFloat in the condition.
• rt.NativePrimsIntact now inlines (its LG_GUARD_DEBUG path moved to a cold function). It runs once per guarded site, which in these loops is once per element, so every guarded native-primitive call now pays one atomic load instead of a call.

Measured

Indicative only: three runs each on one machine, not ratchet results. sum-arr over a 1M double-array, 50 reps, Apple M2, Go 1.27.1, load under 7:

	ms/rep
Bytecode VM	232-263
AOT before (rt.CoreAgetf, rt.AddValue)	27-31
AOT after	0.95-1.03
Hand-written Go over []float64	0.93-0.99

The lowered loop is arg__1, callErr = arg0.AtFloat64(i), s = s + arg__1, on arg0 *vm.TypedArray and s float64. The kernel, the three Go shapes it brackets and the generated Go before/after are in mparrett/let-go-lab#52.

Verified

• New tests: pkg/ir/lisp_lower_go_array_test.go (hinted aget lowers to AtFloat64 with no AddValue; aset widens an int value; the constructor types a local; ^longs uses the int64 accessors; a vm.Value arg into an array param is guarded with the kind check; a long-array or a string into a ^doubles sibling bails to the trampoline; an unhinted param keeps today's path) and pkg/vm/typed_array_lowered_test.go (accessors share the backing store with Get, bounds and kind errors are errors, not panics).
• An end-to-end program with out-of-bounds, negative, wrong-kind and non-array calls under try prints the same lines compiled as interpreted.
• make generate, make check-generated, go test over pkg/vm, pkg/ir, pkg/rt/..., pkg/genmanifest, pkg/compiler/...; gofmt; linux, js/wasm, plan9 and wasip1 builds; the scoped comment lint over the touched files reports only pre-existing lines.

Wiki

concepts/typed-arrays.md describes the pre-PR state (the data any struct, "what the lowering does with an array: nothing", "why it stops there") and concepts/go-backend.md lists the proven types as scalars only. Both become stale on merge; I will send the wiki update once this lands.

Not in this PR

• Hoisting the accessor's slice out of a loop. Once the accessors inline, the per-access and hoisted forms time the same, so there is nothing to hoist.
• A vm.Value index. The intrinsic needs a native int; a boxed index keeps the boxed path.
• Vectors, transients and strings stay on AOT lowering: native homogeneous collections #358.
• Found on the way, independent of arrays: a loop whose body is (when test (side-effecting-call) (recur …)) fails in legalize ("expected int64, got Keyword") on main too; the if/do spelling lowers. Filed separately.

🤖 Generated with Claude Code

[mparrett]

self-review

Reviewed ed17f627e79d9bf9b4ff65b8168529c7d0962d54 against e9789b7d534cce6a570fc0781f220f07c30be17e.

[P2] Preserve array kind safety across function-level recur

For (defn f [^doubles a n] (if (< n 1) (aget a 0) (recur (long-array 3) (dec n)))), calling f with a double-array and n = 1 returns 0 in bytecode and in the base revision's lowered code. This PR's lowered code instead returns double-array expected, got int-array: recur-fn-arg-expr sees the same Go type (*vm.TypedArray) and assigns the long-array into a0, while the hinted array kind remains :float and the next iteration calls AtFloat64. The new kind guard in coerce-arg-to-type only covers ordinary calls, so it never runs on this back-edge. A non-array recur operand can also produce uncompilable Go (a0 = vm.String("x")). Validate recur operands against the parameter's lattice kind and keep the function boxed or fall back to bytecode when that kind cannot hold across iterations. Cover this with a generated-Go execution test.

Validation: the new array lowering/accessor tests and the full pkg/ir, pkg/vm, pkg/rt/..., and pkg/compiler suites passed. Generated-Go probes reproduced both the kind error and the non-array assignment compile failure. The pkg/rt run passed after allowing its local HTTP test listener outside the sandbox.

Overall correctness: incorrect due to the reproduced recur regression.

[mparrett]

Self-review finding addressed in 669ece0

[nooga]

Re-reviewed the current head against main. The prior function-level recur finding is resolved: a changed or unproven array kind rejects native lowering, and the rejected sibling is removed from the direct-call registry. Stable kinds remain native. Array arguments carry lattice kinds alongside their common Go pointer type, and call-site guards preserve the boxed fallback.

Local verification at the #1060 stack tip: VM, compiler, bytecode and IR suites pass, including the array accessors, call guards and recur regressions. An additional generated-Go execution probe produces [0 0.0] under both native and bytecode for changing/stable recur kinds, with confirmed native dispatch of its run entry. No actionable finding in this delta. Performance claims were not remeasured.

[mparrett]

What follows is Claude's, posted under my account.

@nooga You approved the pre-rebase head, so one change since then: the rebase onto main picked up #1017, which changed how lowered code calls a sibling it doesn't link directly. It now emits rt.CachedVarFnEC(ec, …) where it used to emit rt.CachedVarFn(…). 36b469df updates the one assertion in TestLowerGoArrayRecurFallbackCallerUsesTrampoline that spelled the old helper; the test still checks that the rejected sibling is reached through its var. Nothing else changed apart from regenerated files, and CI is green.

[nnunley]

Correctness reads right to me: the recur back-edge check, the kind guard on direct calls, and the join rule (different array kinds join to :any) keep a wrong kind from reaching the accessor. One thing before merge: the timings in the description are three same-machine runs, and AGENTS.md says perf claims go through docs/perf/ratchet.md, so either route them there or label them as indicative. I left a note on the struct layout inline; it isn't blocking.

[nnunley]

Not blocking. I measured the layouts in a standalone copy on go1.27.1: a one-element double-array goes from 56 B in 3 allocs (the slice header in data any was its own allocation) to 120 B in 2, so 64 more bytes per array but one fewer alloc. If the size matters, one layout keeps both: kind, ptr unsafe.Pointer, and one length field per kind with only the live kind's set, so a wrong kind sees length 0 as the nil slices do now. That is a 48-byte struct, 56 B in 2 allocs, and AtFloat64/SetFloat64 still inline (cost 78 and 79), though that is close to the budget of 80 and it brings unsafe into TypedArray. Your call.

[mparrett]

What follows is Claude's, posted under my account.

Keeping this layout. Your measurements give the trade: 64 more bytes per array and one fewer allocation, against unsafe in TypedArray and AtFloat64 at 78 of the 80 inline budget. Staying under that budget is why the struct has a field per kind, so I'd rather keep the headroom. The kernels this targets use a few large arrays, where 64 bytes each doesn't register. If array count shows up in a profile, your compact layout is the fix.

Separately, per your review, the description's timings are now labeled as indicative same-machine runs.

[mparrett]

What follows is Claude's, posted under my account.

@nooga @nnunley One commit since your approvals changes typeinfer code, so I'm holding the merge until one of you has looked at it.

Rebasing onto main after #1038 and #1039 merged broke two tests here: TestLowerGoLongsHintUsesInt64Accessors and TestLowerGoArrayRecurSameKindStaysNative. Their lowered Go no longer used the native accessors (AtInt64, AtFloat64).

The cause is the ordering problem #1038 fixed for the transient ops. This PR's aget and aclone arms in call-core-type returned nil while the array operand was still :bottom, so a call visited before its array constructor joined to :unknown. The trailing typeinfra epoch used to correct that. #1039 skips the epoch when no middle pass edited the function, so the call stayed :unknown and lowering fell back to generic calls.

6b206e2d gives aget and aclone the same rule as #1038: a :bottom array operand keeps the call :bottom until the operand resolves. Before the change, both tests fail on the rebased branch; with it, they pass, along with the rest of the suite apart from test/e2e, which CI runs. check-generated passes.

If the change looks right, please re-approve and I'll merge this, then #1058 and #1060.

[nnunley]

Since this PR opens up native numeric kernels, here is a numeric simplification design I sketched earlier and never shipped, in case it's useful next to this work. Refs #268.

The idea is one dedicated numeric pass in the IR pipeline, not rules spread across constfold and typeinfer:

• Phase A (shipped in passes/constfold.lg): fold const operands, and +0, -0, *1, *0.
• Phase B: commutative canonicalization so CSE sees one form, and chain reassociation, (+ (+ x 1) 2) → (+ x 3).
• Phase C: the identities live as attributes on the op catalog (:commutative, :identities, :fold), and the fold code is generated from it (Consolidate IR op definitions into single-source catalog (multimethods/macros) #268).
• Later: same-operand identities ((- x x), (bit-and x x)), (* x -1) → negate, and value facts such as x≠0 for (/ x x) from a range domain, not from typeinfer.

The constraints: a fold refuses on overflow and on divide by zero, as the VM does; mixed Int/Float goes through vm.NumAdd and friends; gt/lt swaps keep NaN semantics; and inc/dec stay intact for the VM's fast opcodes.

One thing this turned up: Phase A's (* x 0) is wrong for doubles. Under *ir-compile*, (defn f [x] (* x 0)) gives 0 for 1.5, ##NaN and -2.0, where bytecode gives 0.0, NaN and -0.0. It should fold only when x is known to be an Int. Filed as #1071.

[nooga]

Looked at 6b206e2: aget/aclone keep the call :bottom while the array operand is :bottom, the same rule #1038 gave the transient ops. check-generated and check-generated-manifest pass; vm, compiler and ir suites green. Re-approving. Merge order: #1057, #1058, #1060.

[mparrett]

@nooga Thanks for the review! Merging.