Reference type support in MachInst backend and on AArch64

[cfallin]

This PR adds support for reference types in the MachInst backend framework and on AArch64. It comes in two parts: the initial support for allowing R32/R64 types to flow through the Wasm program and call boundaries, and the implementation of opcodes that support them (is_null, etc.); and then stackmap support to allow GCs to occur while Wasm stackframes are active.

This has been tested with SpiderMonkey and is known to work there with GCs occuring during calls from Wasm into JS. We plan to do further testing in regalloc.rs directly (with our checker) too.

This requires a regalloc.rs version bump (with bytecodealliance/regalloc.rs#79 included) and dep version update; the CI build here will be red until that change is made.

[github-actions]

Subscribe to Label Action

cc @bnjbvr

This issue or pull request has been labeled: "cranelift", "cranelift:area:aarch64", "cranelift:wasm"

Thus the following users have been cc'd because of the following labels:

• bnjbvr: cranelift

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

[cfallin]

This is wrong. i128 is supposed to be stored as two i64, just like i64 is supposed to be stored as two i32 on 32bit systems. Storing it in a vector register makes it a lot harder to generate efficient math operations for i128.

Fair enough, removed. It was used internally (produced by and matched by the ABI code) to communicate to store_stack / load_stack that a store/load needs to handle the whole 128-bit vector register, in the case that the regalloc cannot provide a vreg/type associated with a spill. In other words this match arm would not have been triggered by an I128 in the incoming CLIF. But the regalloc should not do this in practice (it only lacks a vreg for a spill/reload when it is a reference from a realreg being spilled to a stackmap slot), so we can just remove the match case. I would expect that when we implement true I128 support, we would lower it to 64-bit ops, and the spill/reload code would not need to reason about I128s.

[cfallin]

Rebased to latest and updated to use support in regalloc.rs that was just merged. The PR to do a new release of regalloc is pending, so this depends on the bytecodealliance/regalloc.rs repo and git hash directly, to let CI work; will update this before a any merge.

@julian-seward1, this should be ready for review now!

[cfallin]

(Actually, spoke too quickly re: regalloc -- we just released 0.0.27 so the dep in this PR can use that now.)

[cfallin]

Rebased again after changes to x64 backend.

@julian-seward1 or @bnjbvr, would you mind reviewing this soon before we land additional new-backend PRs, to reduce the rebase overhead somewhat? Thanks!

[julian-seward1]

Looks plausible to me (thanks for doing all this). OK to land providing two things are addressed:

• unexpected types::R32s appearing (as commented below)
• assure me we're not going to be calling LowerCtx::is_safepoint on every insn.

[cfallin]

Addressed, thanks!