Stream: git-wasmtime

Topic: wasmtime / Issue #2223 Support for SpiderMonkey's "Wasm A...

view this post on Zulip Wasmtime GitHub notifications bot (Sep 23 2020 at 23:49):

github-actions[bot] commented on Issue #2223:

Subscribe to Label Action

cc @bnjbvr

<details>
This issue or pull request has been labeled: "cranelift", "cranelift:area:aarch64", "cranelift:meta"

Thus the following users have been cc'd because of the following labels:

To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.
</details>

view this post on Zulip Wasmtime GitHub notifications bot (Sep 24 2020 at 17:56):

cfallin commented on Issue #2223:

Updated for x64, thanks! I see a few failures on SpiderMonkey-x64 with e.g. jit-test/tests/wasm/bigint/bigint.js (and I have to test with --no-wasm-simd to get Cranelift now on x64); I'm not sure if this is pre-existing, since we don't run the new x64 backend on CI there; but all of the basic functionality seems to work, so the basic stack-slot setup in this PR should be correct, I think.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 29 2020 at 21:03):

cfallin commented on Issue #2223:

Updated -- that was a fun one to track down! (Ten points to Gryffindor rr...).

The problem is that we weren't restoring the TLS register in the epilogue -- unlike IonMonkey, we do not treat the TLS register as an unallocatable fixed register, but rather we just copy its value to an ordinary SSA value on function entry. Apparently we were free to clobber it previously, but now we are not. Easy enough to handle in the clobber-restore sequences.

When vendored in, this passes SpiderMonkey's jit-tests on both x64 (--wasm-compiler=cranelift --no-wasm-simd) and aarch64 (--wasm-compiler=cranelift).

Last updated: Nov 22 2024 at 16:03 UTC