compiler: pass large aggregate parameters indirectly (#5615)

[neomantra]

As described in #5615, we need to spill aggregate parameters. This has been worked over and reviewed by humans and LLMs. I tested it against some BubbleTea programs, as well as the tests described below. I finally got BubbleTea Lists working with WASM, but there's another issue that needs resolved.

The below is LLM-generated. I have read and reviewed it as well as the code.

---

Summary

Pass aggregate parameters with more than 16 scalar leaves through backing storage in the Go-internal ABI, so each parameter contributes at most 16 scalars after WebAssembly scalarization. This is a practical mitigation of the JS embedding's 1,000-parameter limit rather than whole-signature enforcement: exceeding the cap now requires a function with more than 62 parameters, far beyond any signature observed in practice (the worst real Bubble Tea offender was a single receiver with thousands of leaves). Exported/C-ABI signatures are deliberately unchanged — their ABI is externally visible and cannot be respilled — so an exported function with huge aggregate parameters can still exceed the cap.

Fixes #5615.

Problem

LLVM's WebAssembly backend recursively scalarizes struct-by-value parameters. A single lipgloss.Style has roughly 95 scalar leaves, and value receivers such as bubbles/list.Model contain many Styles. Before maxDirectAggregateValues, real Bubble Tea functions produced wasm types with thousands of parameters (3730 / 4316 measured); browsers reject any function type above 1000 parameters, and wasmparser-based tooling (wasm-tools et al.) rejects such modules too.

Current dev already has a generalized indirect-aggregate engine (maxDirectAggregateValues = 1024, from #5526). That threshold was chosen to protect LLVM itself — SelectionDAG's 65,535-value representation limit and the compile-time cliff before it (#5477) — but it does not protect the stricter whole-function JavaScript embedding limit: several individually smaller aggregate parameters can still exceed 1000 in total. This PR extends #5526's approach (preemptive indirection before LLVM, exported types unchanged) with a lower threshold on the parameter side for that external limit. Measured on dev (f71b630 and current 86d58db): the bubbles list-fancy example's largest function type is at 995 params — five below the cap — and a 25-line program with two 600-leaf struct params (see the issue) emits a 1200-param type that wasm-tools refuses to parse.

Implementation

• Count scalar leaves through nested structs and arrays and spill a Go-ABI parameter above 16 leaves.
• Reuse current dev's indirect-value storage, copy, GC tracking, result, defer, and goroutine machinery rather than restoring the branch's older parallel implementation.
• Keep exported/C ABI parameters unchanged.
• Make interface invoke wrappers use the same indirect receiver decision while preserving exported method ABI. When an exported method's result or a non-receiver parameter is a large aggregate, the C ABI and the interface invoke thunk's Go-internal ABI place the value incompatibly; that case now produces a clear compile error instead of miscompiling. For results (and parameters above 1024 leaves) this was already broken on current dev — an exported method with a [1025]byte result through an interface crashes dev's compiler with a slice-bounds panic in getInterfaceInvokeWrapper. For parameters between 17 and 1024 leaves the error is a knowing trade-off: dev compiles and runs that narrow combination correctly (it doesn't spill below 1024), and restoring it under the lower threshold would require a full C/Go ABI bridge in the wrapper, which can be added separately if the combination matters in practice. The error path is covered by the compiler-errors test, whose harness now also fails on missing expected errors.
• Materialize indirect phi inputs in their predecessor blocks before the terminator. The lower threshold exposed late phi copies that otherwise landed after a branch/return in real bubbles/list functions ("Basic Block ... does not have terminator").
• Add unit coverage for the 16/17 boundary and arrays, golden IR coverage for direct calls, function values, interface receivers, exported ABI, goroutines, and phis, plus a GC-stressed behavioral test for direct/func-value/interface/defer/goroutine paths. The function-value coverage is a genuine indirect call: the callee is hidden behind a //go:noinline picker so StaticCallee() is nil, and the golden pins the func-value decode (code-pointer extraction, nil check, indirect call with the spilled parameter). The phi golden pins real phi ptr nodes for both an if/else merge and a loop back edge, with incoming values (a constant and a plain load) that require predecessor materialization — reverting the phi placement fix makes this test fail with the same malformed-IR error seen in the real Bubble Tea build.

Verification

• go test -tags llvm22 ./compiler -run '^TestParamNeedsSpill$' -count=1 -v
• go test -tags llvm22 ./compiler -run '^TestCompiler/paramspill.go$' -count=1 -v
• go test -tags llvm22 ./compiler -run '^TestCompilerErrors$' -count=1 -v — includes the new exported-method-through-interface diagnostics; the strengthened harness fails if an expected // ERROR: is not produced.
• go test -tags llvm22 . -run '^TestBuild/Host/paramspill.go$' -short -count=1 -v
• go test -tags llvm22 . -run '^TestBuild/WebAssembly/paramspill.go$' -count=1 -v
• go test -tags llvm22 ./compiler -count=1
• Exported-method probes: a method with a [1025]byte result called through an interface now fails with the clear diagnostic (the same program crashes current dev's compiler); a supported exported method (17-leaf value receiver, small result) called through an interface returns correct values at runtime.
• Built Bubble Tea examples/list-fancy with GOOS=js GOARCH=wasm: success with no Binaryen large-parameter warning.
• wasm-tools validate: success.
• Type-section inspection: 74 function types; maximum parameter count 17 (type 43), down from 995 on current dev (and 3730/4316 before maxDirectAggregateValues), safely below 1000.
• The minimal two-param repro from the issue builds a module that wasm-tools parses and validates.

All of the above were run against the branch head after the final rebase onto dev @ 86d58db.

Note on goroutine arguments

This PR deliberately contains no goroutine-specific spill code: dev's existing getGoroutineCallArgument + copyToIndirectStorage path already gives spilled goroutine arguments a GC-safe heap lifetime, and the spill predicate plugs into it unchanged. The behavioral test still covers the goroutine path (a spilled argument surviving the spawner's return, under GC stress) to pin that reuse.

[jakebailey]

I'm not sure I like this fix (seems a bit too AI-special-case-y); I'm looking into this problem separately just to convince myself of that, though.

[neomantra]

Thank you for your patience in reviewing. While I can understand code diffs, I have limited experience in compiler/LLVM domain. Chopping and shaping trees, without traveling the forest.

It did seem natural to me to extend spilling to more circumstances and I only really worked to release the PR after the other spilling work (it was a much more complicated changeset last month).

I pushed on this further since yesterday, particularly I didn't like that we still had to bump the stack size (targets: raise wasm default goroutine stack size to 128KB commit). That ends up being related to slot allocation lifetime management: "transform.OptimizeAllocs promotes small non-escaping heap allocations to entry-block allocas but emits no llvm.lifetime intrinsics".

If there's anything you want me to explore on this, I'm happy to put the energy in to advance it, while trying to be considerate of the review/integration effort.