Multi-value return support on aarch64/Wasmtime.

[cfallin]

This PR adds support for multi-value returns to the new aarch64 backend's ABI implementation, using an ABI that should match that of SpiderMonkey's Wasm baseline compiler on aarch64.

The existing multivalue Wasm spec-tests pass; curiously, these did not seem to actually be disabled before, so the rudimentary "return values in x0..x7" ABI that was previously implemented actually was sufficient. Nevertheless, it seems most reasonable to standardize on the SpiderMonkey-style struct-return-area ABI so that we don't need to maintain two different schemes.

I have not yet been able to test this in SpiderMonkey; we first need to resolve the newly-failing tests on an Cranelift version bump on the SM side, and then I need to work out how to cross-compile SM, since I'm back to working on an x86 host for now. Putting this up for review now in any case, and can tweak if need be as we work out the above.

[github-actions]

Subscribe to Label Action

cc @bnjbvr

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

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.

[bjorn3]

The SystemV abi on AArch64 uses x0 and x1 to return pairs of integers. Could you please do that in Cranelif too? Even if only in the non baldrdash variant of the abi?

[cfallin]

The SystemV abi on AArch64 uses x0 and x1 to return pairs of integers. Could you please do that in Cranelif too? Even if only in the non baldrdash variant of the abi?

Happy to take a followup patch for this, but perhaps not in the initial patch, if only because I don't have a way to test it easily. As far as I can tell, the principle in the past (e.g. in #1178) was to keep the ABI as simple as possible initially. I'm not opposed to declaring that we achieve full SysV ABI compatibility eventually, but it's a higher bar for sure!

[bjorn3]

Keeping the abi simple is fine, but I want to have all the primitives necessary to implement full SystemV abi support from the clif ir producer side.

[cfallin]

@bjorn3: after more thought, I think it actually wouldn't be too bad to at least give a "all return values are in registers; error if > K returns" (K = 8 on aarch64?) mode. Perhaps we can define this to be the default if we're not in Baldrdash (SpiderMonkey) mode. This would give you the building blocks needed to legalize whatever other ABI (SysV or otherwise) down to CLIF. Does that sound reasonable?

[bjorn3]

👍

[cfallin]

Updated to return values in x0-x7 by default.

@bnjbvr, PTAL -- I think we'll need to land this first before we can version-bump vendored Cranelift in SpiderMonkey and fix the issues there. Thanks!

[bnjbvr]

LGTM, thanks! Nice that we can support both Baldrdash and be compatible with the native Rust ABI on the first try :)

[bnjbvr]

Nice addition, thanks.