cranelift: inline small constant-length array.copy

[gfx]

Small, statically-sized array.copys of scalar elements currently go through the memory_copy libcall, just like every other size. For tiny copies the libcall's fixed per-call cost — a wasm↔host transition plus an indirect call — dominates the actual memmove, so array.copy is far slower than it should be for small fixed-size copies (enough that a hand-written array.get/array.set loop can beat it).

This PR expands such copies inline, as a sequence of loads followed by stores, when the element type is scalar and the length is a compile-time constant of at most 8 elements.

Speed

array.copy of N i32 elements, ns per copy, release build, lower is better:

N	before (libcall)	after (inline)	speedup
1	4.60	1.27	3.6×
2	3.36	1.27	2.6×
4	4.17	1.43	2.9×
8	4.88	2.00	2.4×

The inline path also beats the manual element-by-element loop that was previously the faster workaround. The gap is larger still in unoptimized builds, where the libcall body itself is not optimized (~24 ns/call drops to a couple ns).

Methodology

ns per whole-array copy = (wall time at N iterations − wall time at 0 iterations) / N, taking the min of several repetitions, default config, x86_64. The 0-iteration baseline cancels out module compilation and array allocation. The "before" column is measured with a dynamic length (forcing the libcall) and the "after" column with a constant length (inline), at the same N.

Correctness & scope

• Every element is loaded before any is stored, so overlapping source/destination ranges keep array.copy's memmove semantics.
• Dynamic or larger lengths, and tables, still use the memory_copy libcall — there its memmove amortizes the call overhead.
• The bound of 8 elements comes from measurement: the inline-vs-libcall crossover is around 16 elements, but the largest wins cluster at ≤ 8 while inline code size grows with the element count.

Tests

• tests/disas/array-copy-inline.wat locks the codegen (the libcall is gone; loads-then-stores remain).
• tests/misc_testsuite/gc/array-copy-inline.wast checks correctness for every element size (i8/i16/i32/i64/f32/f64/v128), the threshold boundary (8 inline vs 9 libcall), and overlapping copies; the wast harness runs it across the DRC, null, and copying collectors.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds an optimization to inline small, statically-sized array.copy operations in Cranelift to avoid the fixed overhead of the memory_copy libcall, and introduces tests to lock down both codegen shape and runtime semantics.

Changes:

• Inline-expand constant-length array.copy for small copies (<= 8 elements) into explicit loads+stores with memmove semantics.
• Add runtime GC tests covering element sizes/types, overlap semantics, and the 8/9-element threshold.
• Add a disassembly-based “shape” test to ensure the inline expansion remains stable.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
tests/misc_testsuite/gc/array-copy-inline.wast	New runtime tests validating correctness across element sizes, threshold behavior, and overlap (memmove) semantics.
tests/disas/array-copy-inline.wat	New disassembly test to lock in the expected inline load-then-store codegen sequence.
crates/cranelift/src/func_environ.rs	Implements the inline expansion for small constant-length array.copy and a helper to detect constant lengths.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.