Wasmtime GitHub notifications bot (Feb 03 2021 at 20:40): Wasmtime GitHub notifications bot (Feb 03 2021 at 20:40):bjorn3 commented on Issue #1163:
Does this work with the new backends?
Wasmtime GitHub notifications bot (Feb 03 2021 at 20:49):cfallin commented on Issue #1163:
Yes, we support multivalue returns in a SpiderMonkey-compatible way now.
Wasmtime GitHub notifications bot (Feb 03 2021 at 20:49):cfallin closed Issue #1163:
In a WebAssembly + Firefox context, the goal is to replace the optimized compiler tier with Cranelift, but keep the quick-and-dirty Baseline compiler. In that context we will need some coherence in ABI between Cranelift and Baseline. I think some of the recent excellent work by @fitzgen to add multi-value support to Cranelift (#1147) might need some adaptation, in this regard.
To back up a bit, I'm going to try to summarize the situation. Corrections welcome.
Baseline's goal is to produced compiled code soon. Doesn't have to be good code; we leave that to the optimized tier (Cranelift, eventually). To produce good code soon, Baseline uses a compilation strategy that mirrors WebAssembly's stack discipline to the machine stack. If a program does this:
local.get 1 local.get 2and these values get spilled to the stack, local 2 will be closer to the machine stack pointer than local 1. In Baseline, any value allocated to a register will have been pushed on the WebAssembly abstract stack more recently than any value spilled to the machine stack.
Multiple function return values also follow a stack discipline. Consider a function that returns three values v0, v1, and v2. Let us assume that there's only one register allocated to function returns, so one of the values goes to a register, and two to the stack. Following the invariant about registers being more recently pushed than stack results, that means v0 and v1 should go on the stack, and v2 should be allocated to a register. Furthermore, it means that v0 should be farther from the SP than v1.
Needed changes in Cranelift
- Cranelift and Baseline should agree (in the baldr ABI) on which results get allocated to registers and which to stack locations.
- Cranelift and Baseline should agree on how to find stack locations for stack results (an extra synthetic argument).
Related: WebAssembly ABI 2020
Related: ABIResultIter
I am pretty sure that some of the choices in bytecodealliance/cranelift#1147 didn't match up with the WebAssembly stack discipline. Not a problem for Cranelift of course, but I think it is a problem for Baseline. Thoughts?
cc @Dima00782 @bnjbvr @fitzgen @lars-t-hansen
Last updated: Nov 22 2024 at 16:03 UTC