Method with i64 return type fails on Safari 13+14

[yonihemi]

Using JavaScriptKit as only dependency, trying to instantiate a Date() fails on Safari (13.1.1, 14) with:
TypeError: i64 not allowed as return type or argument to an imported function

Stacktrace

TypeError: i64 not allowed as return type or argument to an imported function

wasm-stub
<?>.wasm-function[gettimeofday]
<?>.wasm-function[CFAbsoluteTimeGetCurrent]
<?>.wasm-function[$s10Foundation4DateVACycfC]
<?>.wasm-function[main]
<?>.wasm-function[__original_main]
<?>.wasm-function[_start]
wasm-stub
_start
(anonymous function) — e8900d1b3895f276.js:1:47960
(anonymous function) — e8900d1b3895f276.js:1:184568
asyncFunctionResume
[native code]

Same code runs fine on Chrome and Firefox. Tried with latest blessed carton versions and with latest swiftwasm+JavaScriptKit, same results.

Assuming it's related to swiftwasm/JavaScriptKit#56. Could/should we incorporate this polyfill in JavaScriptKit?

[MaxDesiatov]

Is this reproducible with carton? I thought there was a polyfill for this in Wasmer-JS which carton ships in dev.js and bundle.js entrypoints.

[yonihemi]

Unfortunately it is, getting same results with carton init --template basic, then in main.swift:

import Foundation
print("Hello, world!")
let date = Date()

(Running with carton dev/bundle)

[MaxDesiatov]

Here's an issue that seems related to me WebAssembly/WASI#334

[MaxDesiatov]

What people mention there is possible optimization with wasm-opt --i64-to-i32-lowering. If it does work, maybe we could integrate it in carton? It already requires wasm-opt for carton bundle.

[kateinoigakukun]

I addressed this issue by pollyfilling i64 into two i32 values https://github.com/kateinoigakukun/swiftwasm-pad/tree/master/Frontend/Sources/i64_polyfill

[MaxDesiatov]

This would require generating additional SwiftPM modules that contain the polyfills for our users. What do you think about the wasm-opt solution, which if works would be much less intrusive?

[kateinoigakukun]

$ wasm-opt --i64-to-i32-lowering .build/wasm32-unknown-wasi/release/Hello -o Bundle/main.wasm
Fatal: IR must be flat: run --flatten beforehand (instructions must only have constant expressions, local.get, or unreachable as children, in 3)

Hmm, that option doesn't work well. If it works well, it would be an option to recommend.

[yonihemi]

I didn't have luck with wasm-opt either. There's also wasmer's lowering pass which we can use at runtime, presumably only if needed by browser detection.

[MaxDesiatov]

BTW, I hope JSDate works well in Safari, and would be enough to substitute the functionality of Foundation's Date in the meantime.

[yonihemi]

I've had some success running the i64->i32 transformer directly in rust on the pre-optimized bundle. It fails on optimized bundle and when running in javascript.
JSDate does work in Safari, but naturally untenable for reusing 'real' Swift code. I guess it also affects a bunch of other WASI methods.

[MaxDesiatov]

Do I understand correctly that polyfilling this purely on JS side or even within the Swift codebase of JavaScriptKit is not possible? Maybe this issue should be transferred to either toolchain or carton repositories then? Depends on where exactly we're going to apply the final i64->i32 transformation .

[MaxDesiatov]

(For posterity, this is also tracked in WebKit).

[MaxDesiatov]

Today and yesterday I've been playing with Binaryen bindings, and binaryen is what powers wasm-opt. If we can get its i64-to-i32-lowering pass to work, it could be easily integrated in carton and applied during the build.

[yonihemi]

I'll try to look into that. Meanwhile I realized the wasmer js transformer is not working because... the rust->wasm module it's running itself has i64 calls. I've been trying to transform the transformer offline but got bogged down in rust and npm failures.

[MaxDesiatov]

the wasmer js transformer is not working because... the rust->wasm module it's running itself has i64 calls.

oh dear

[yonihemi]

I've seen your great progress on https://github.com/MaxDesiatov/binaryen. But not sure it's the right way forward:

1. We already fork to wasm-opt, so not sure of the benefit of building it into carton.
2. More importantly, binaryen's lowering pass doesn't seem to handle our output wasm well.
   • On the most simple example, yields Fatal: IR must be flat: run --flatten beforehand (instructions must only have constant expressions, local.get, or unreachable as children, in _start)
   • Running flatten as suggested crashes with

warning: invalid abbreviation code 23 (range: 61 : 0..69)
compile unit size was incorrect
UNREACHABLE executed

Wasmer's pass does seem to handle our output, though I've only ran some rudimentary tests. We can incorporate it either:

• Bundling wasm_transform_cli, though it seems more of a demo than a fully fetured tool;
• Linking the rust code into carton, which is doable (though I'm not familiar with the Linux mechanics of that), or
• Fix the i64 issue and use the rust->wasm->js version, (1) in runtime or (2) as our own pass in carton bundle, say with wasmer cli.

[MaxDesiatov]

Thanks for the detailed update!

I've seen your great progress on https://github.com/MaxDesiatov/binaryen.

To clarify, there's not much there, and I'm thinking of abandoning that repository for now and merging my work into previously available bindings, which I weren't fully aware of. I knew there were some, but didn't know their API coverage was much greater than what I managed to get on my own.

My foray into Binaryen bindings was provoked by dreaming of a Swift to WebAssembly compiler running directly in the browser. This is not something I plan to work on very soon, but rather an exploration in background. LLVM is too heavy, so I wonder how difficult it would be to take the Swift compiler frontend as is, get SIL output from it, and then transform SIL (at least some very limited subset of it as PoC) to Wasm with Binaryen. This is a long-term project, and fixing high priority issues we have in SwiftWasm right now is what I'm focused on. I only hoped that Binaryen bindings could bring me one step closer to that Binaryen compiler backend PoC.

1. We already fork to `wasm-opt`, so not sure of the benefit of building it into carton.

Forking has some overhead, especially for frequent builds as we have to run for carton dev too. Additionaly, we have more control with direct bindings, maybe even allowing us to write our own optimization passes in Swift.

But you've convinced me that trying wasm_transform_cli in some form is probably the best approach for now.

[MaxDesiatov]

wasm_transform_cli works for me, but it will require Rust to build this dependency for carton, which is not ideal. The transformer itself is ~400 LoC, I wonder how hard it would be to rewrite it in Swift with Binaryen bindings...

[MaxDesiatov]

Moving it to the carton repo in the meantime, I don't think any changes in JavaScriptKit will be necessary.

[kateinoigakukun]

I'll work on porting wasm_transform_cli in Swift world

[MaxDesiatov]

Looks like Binaryen bindings with full API coverage I was referring to are in a bit broken state, I'm fixing those right now.