1571998 - Implement wasm tail calls

Status: RESOLVED FIXED

(Core :: JavaScript: WebAssembly, task, P1)

Description

[Andy Wingo [:wingo]]

This patch will add parser and validator support for WebAssembly tail calls. Any attempt to compile a function with a tail call will MOZ_CRASH.

We also add a new #define, ENABLE_WASM_TAIL_CALLS, a new configure flag --enable-wasm-tail-calls which is on by default in nightly and off otherwise, and a new run-time flag --wasm-tail-calls which is off by default.

Comment 1

[Andy Wingo [:wingo]]

Attachment: Bug 1571998 - Implement front-end support for wasm tail calls

Comment 2

[Lars T Hansen [:lth]]

Attachment: WIP: Bug 1571998 - Tail-call scaffolding + simulate return_call by call+return

Standard ifdeffery, some simple tests, and some placeholder logic that
implements return_call in terms of call+return. It does run, and will
appear to be correct, given unbounded stack space.

Depends on D138879

Comment 3

[Lars T Hansen [:lth]]

Attachment: WIP: Bug 1571998 - Round up stack argument area size

Depends on D138898

Comment 4

[Lars T Hansen [:lth]]

Attachment: WIP: Bug 1571998 - Handle the multiple-value return area in baseline tail calls

Also more test cases.

Depends on D144158

Comment 5

[Lars T Hansen [:lth]]

Attachment: WIP: Bug 1571998 - Handle the multiple-value return area in Ion tail calls

Depends on D144398

Comment 6

[Lars T Hansen [:lth]]

Attachment: WIP: Bug 1571998 - Tail calls for the baseline compiler

Uncertain here still about whether more rawCaller / wasmCaller sites need to be handled
in the unwind logic.

Depends on D144399

Comment 7

[Lars T Hansen [:lth]]

Attachment: WIP: Bug 1571998 - Tail calls for the baseline compiler (WIP)

Some of the code here belongs in the previous patch, because it cleans
up some mechanisms introduced there.

Comment 8

[Lars T Hansen [:lth]]

Friday night / pre-long weekend status: All my tests (included in the queue) pass on x86 and x64, but on arm64 there are assertions for test cases with return_call_indirect, so it looks like the unwind information is not right - not a surprise. Other platforms are not supported but arm, mips64, and loong64 will be like arm64, by and large, and there are very few platform dependencies for now.

The base rev is 0914de230f91.

Comment 9

[Lars T Hansen [:lth]]

Attachment: WIP: Bug 1571998 - Ion sketches (WIP WIP WIP)

Depends on D144946

Comment 10

[Lars T Hansen [:lth]]

Attachment: WIP: Bug 1571998 - Masm, patching, and unwinding support for tail calls

Depends on D144399

Comment 11

[Lars T Hansen [:lth]]

Attachment: Bug 1571998 - Test cases for tail calls. r?rhunt

Author of syntax and validation tests: Andy Wingo

Depends on D147199

Comment 12

[Lars T Hansen [:lth]]

The design document is "WebAssembly ABI 2022" and it outlines a strategy for implementing wasm tail calls without major compiler or ABI changes by executing the initial tail call in a chain of tail calls as a non-tail call (so that our same-instance-biased ABI that requires the caller to perform context restoration after return can continue to be used) and subsequent calls in the chain by collapsing the call frame after call setup and then jumping (thus minimizing compiler changes). Given that most calls take only register arguments this strategy is pretty good. More tweaks are possible for stack arguments; see the design document and comments in the code.

The patch queue on this bug implements the strategy for shared code and for the baseline compiler on all tier-1 platforms. The state of the queue is as follows:

• The base revision for the patches is df9a51c997b9
• While the patches are what they are so as to logically separate various ideas and pieces of functionality, it may sometimes be easier to view some changes through the entire patch stack, ie, apply the stack and hg diff -r <baserev>. This may in particular be true for the baseline compiler changes.
• All test cases pass in the baseline compiler with arbitrary tail-call depths and the baseline code is assumed to be working correctly.
• There are many optimizations possible in the baseline code, and these will make the generated code quite a bit tighter by removing redundancies. They are noted with TODO comments in the patch.
• The greatest uncertainty is around unwinding support. The new FP tag needs to be removed during unwinding, and that logic is a little tricky, especially around rawCaller(). See commit message on the unwinding patch. Further insight might be found in patches on bug 1742053, but this is not an easy thing.
• Ion code still needs to be implemented to correspond to the last baseline patch, and the "Ion sketches" patch is not complete, it really only is a sketch. See the design document for more information about this.
• In the code, tail calls are variously called "tail calls" (this is what they are) and "return calls" (this is the wasm nomenclature). It would be meaningful to standardize on one or the other. Fixed this: it's return_call for the opcode name and in the opcode reader, "tail call" everywhere else.

Comment 13

[Yury Delendik (:yury)]

Attachment: Bug 1571998 - Wasm return calls implementation. r?rhunt

Comment 14

[Yury Delendik (:yury)]

Attachment: Bug 1571998 - Wasm return calls implementation for Ion. r?jseward

Depends on D166353

Comment 15

[Yury Delendik (:yury)]

Attachment: Bug 1571998 - Use FramePointer to restore StackPointer after wasm calls. r?rhunt

Changes JS->Wasm stubs logic to expect SP being clobbered by Wasm function.

Changes baseline code to use FP to restore SP to pre-call value.

Comment 16

[Yury Delendik (:yury)]

Attachment: Bug 1571998 - Wasm return calls spec tests. r?rhunt

Comment 17

[Yury Delendik (:yury)]

Short description of the current approach:

1. The wasmCollapseFrame is introduced at masm level: the operation will remove caller/middle frame by moving parameters, instance slots. RA and FP will be used to transfer control to the callee via direct jump.
2. The return call caller will prepare parameters on the stack, which will still include its own private frame + its parameters, and then proceed with wasmCollapseFrame. This will also guarantee no data will be written before current SP.
3. Every wasm callsite with slow path will be mark with special carefully selected instruction. During collapse frame, when heap registers and realm is changing, this mark is checked.
4. In case when the caller of the caller (C0) has a fast path (no heap registers and realm will be recovered), new small frame will be inserted before transferring control to the C0 for the short trampoline that will restore heap registers and realm.
5. The stack depth will be changing, so for Ion calls it will be required to restore SP based on its FP.
6. Some consideration has to be taken for the entry stubs (from interpreter or JIT) as well, the SP can be changed, so the entry stub shall anticipate that.

Comment 18

[Yury Delendik (:yury)]

Attachment: WIP: Bug 1571998 - Add return call test that use Wasm GC references.

Comment 19

[Yury Delendik (:yury)]

Attachment: Bug 1571998 - Track unwind info for tail calls. r?jseward,mstange

Comment 20

[Phabricator Automation]

Comment on attachment 9343294 [details]
Bug 1571998 - Track unwind info for tail calls. r?jseward,mstange

Revision D183269 was moved to bug 1846534. Setting attachment 9343294 [details] to obsolete.

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8193b332f032
Use FramePointer to restore StackPointer after wasm calls. r=rhunt
https://hg.mozilla.org/integration/autoland/rev/0bc528704114
Wasm return calls implementation. r=rhunt
https://hg.mozilla.org/integration/autoland/rev/4171d4a90a77
Test cases for tail calls. r=rhunt
https://hg.mozilla.org/integration/autoland/rev/b819214797de
Wasm return calls spec tests. r=rhunt
https://hg.mozilla.org/integration/autoland/rev/89a227f6c1ab
Wasm return calls implementation for Ion. r=jseward

Comment 22

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/8193b332f032
https://hg.mozilla.org/mozilla-central/rev/0bc528704114
https://hg.mozilla.org/mozilla-central/rev/4171d4a90a77
https://hg.mozilla.org/mozilla-central/rev/b819214797de
https://hg.mozilla.org/mozilla-central/rev/89a227f6c1ab

Comment 23

[Vadim Makeev]

You can follow/review the documenting process for the Fx 121 release in these tasks:

• https://github.com/mdn/content/pull/31043
• https://github.com/mdn/content/pull/31040
• https://github.com/mdn/interactive-examples/pull/2693