Transparent & uniform handling of i64 FFI

[TerrorJack]

Currently, WebAssembly as in spec/V8 doesn't support passing i64 across WebAssembly/JavaScript boundary, and the i64 via BigInt proposal isn't landing anytime soon. Before we properly generate 32-bit code (which is going to be a standalone issue later), we still need to polyfill this feature.

Previously, there are multiple different workarounds co-existing in asterius:

• When generating JSFFI stub functions, we always chop off higher 32-bits when passing i64 from wasm to js. See Asterius.JSFFI
• We generate wrappers for RTS API functions exported to js, using the same workaround (but via different functions, see Asterius.Builtins)
• For the debug mode, however, when passing i64 from wasm to js, we pass the higher/lower 32-bits as two parameters, and re-assemble at the other end. See Asterius.Builtins.cutI64.

For more reliable code generation, i64 FFI should be handled in a transparent & uniform manner:

• At the level of pre/post linking IR, we do not generate any wrapper function at all; we assume i64 FFI works out of the box at this level. No ugly __asterius_*_wrapper function exist here.
• When generating wasm binary code/js stub code, we inspect the imports/exports, and insert wrappers in case they are needed. When V8 implements i64 via BigInt proposal, we can remove the wrappers and behavior of generated code shouldn't change.

[TerrorJack]

The i64 to i32 lowering hacks which either passes two parameters or uses a global for higher 32-bits are overly complicated for our use cases. Simpler solution: pass raw bit patterns in f64 instead, so we won't lose higher 32 bits, nor do we need to rely on any global state for function calls.

[TerrorJack]

We now pass i64 as f64 for FFI. Closing this issue for now, since fully transparent handling based on a Module -> Module rewriting is another pile of work and should be scheduled later.

[TerrorJack]

https://bugs.chromium.org/p/v8/issues/detail?id=7741#c8

Finally, V8 guys have made the move!

We won't remove the current hacks immediately since it takes some time for V8's changes to propagate to node.js/chrome, but still worth celebrating.

[TerrorJack]

Revisiting this issue after one year:

--experimental-wasm-bigint landed in V8 but is still off by default. For SpiderMonkey it seems to be a work in progress. So other than "debug mode" we still need to assume the absence of wasm bigint integration for now.

We need this asap for #358. The i64 hash values aren't safe to be assumed to stay within Number.MAX_SAFE_INTEGER range. While we can risk a reinterpret cast or use a global buffer for casting, the real solution IMO is fixing this old issue, and use vanilla i64 parameters & return values in our imported & exported functions.

Reopening this issue since it's relevant again today.

[TerrorJack]

The C/C++ and Rust folks should face a similar challenge. The existing solution seems to be:

• For emscripten: the parameters are turned to a pair of i32s, the result to a temporary i32 which is a handle to extract the higher/lower 32-bits, see https://emscripten.org/docs/getting_started/FAQ.html#how-do-i-pass-int64-t-and-uint64-t-values-from-js-into-wasm-functions
• For wasm-bindgen: parameters are passed on a "global stack" which is a fixed-length static memory region, see https://rustwasm.github.io/docs/wasm-bindgen/contributing/design/rust-type-conversions.html#global-stack

I have yet to find some clang compiled wasi target executables for further investigation. Anyway we should make our solution close to the existing ABIs, to prepare for future introduction of the clang toolchain and cbits support.