1508560 - Remaining anyref-related stubs work

Status: RESOLVED FIXED

(Core :: JavaScript: WebAssembly, enhancement, P3)

Description

[Lars T Hansen [:lth]]

There are several cases in WasmStubs.cpp that crash on encountering AnyRef; these must be implemented properly.

Comment 1

[Lars T Hansen [:lth]]

This will also entail removing "temporarilyUnsupportedAnyRef()" everywhere.

Comment 2

[Lars T Hansen [:lth]]

(Notes to self)

I guess the JS->Wasm and Wasm->JS and Wasm->wasm paths are independent here, more or less.

For the JS->Wasm path, MCallOptimize inserts explicit conversion nodes, pretty much mirroring what the slow path in WasmInstance::callExport does. Generalized to anyref it would also insert an UnboxAnyRef at the return path when appropriate, which callExport also does. But there's still stub code (GenerateJitEntry) that massages input values, which is a little surprising, and then adapts to the register and stack conventions of wasm and makes the call. So maybe this is for general jit code calling wasm but when types or other information are unknown.

For the Wasm->JS path, we have callImport_anyref and its workhorse callImport (in WasmInstance.cpp); these lead directly up into the stubs territory and there's a lot of hair here.

For the Wasm->Wasm path there isn't much magic going on that we have to worry about, the call goes straight through on a fast path and there's neither boxing nor unboxing.

(Generally speaking, temporarilyUnsupportedAnyRef() should become either temporarilyUnsupportedRef() -- since we'll handle anyref properly but not other reftypes, which are complicated in a different way in that they don't require boxing/unboxing but they do require type checks -- or possibly it could be specialized into various functions that guard against optimization along various call paths, since i64 is also unsupported on the js<->wasm boundary at the moment. Though probably not for long.)

Comment 3

[Lars T Hansen [:lth]]

This has been fixed, actually; there's optimization work remaining, but that's adequately covered by bug 1532556, or can be spun off from it.