Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wasmtime: support reference types on aarch64 #1886

Closed
fitzgen opened this issue Jun 16, 2020 · 3 comments
Closed

wasmtime: support reference types on aarch64 #1886

fitzgen opened this issue Jun 16, 2020 · 3 comments
Labels
wasmtime Issues about wasmtime that don't fall into another label

Comments

@fitzgen
Copy link
Member

fitzgen commented Jun 16, 2020

I think this should mostly Just Work after #1617 lands, but we also need to remove these cfgs (and make sure the tests pass, ofc):

  • wasmtime/build.rs

    Lines 214 to 216 in 647d2b4

    // Ignore if this isn't x64, because Cranelift only supports
    // reference types on x64.
    return env::var("CARGO_CFG_TARGET_ARCH").unwrap() != "x86_64";

  • // Cranelift only supports reference types on x64.
    #[cfg(target_arch = "x86_64")]
    mod gc;

@fitzgen fitzgen added the wasmtime Issues about wasmtime that don't fall into another label label Jun 16, 2020
@cfallin
Copy link
Member

cfallin commented Jun 16, 2020

For tracking purposes: the initial support for the ref values and opcodes themselves on AArch64 is in the WIP PR #1852, and @julian-seward1 and I are working out the safepoints story from the regalloc.rs and isel sides respectively. We should have at least an initial version done in the next few weeks.

We're pushing things forward for the SpiderMonkey use-case and planning to test there, so I'll be interested to see how we interface with wasmtime's new reftypes support you've been building. The stackmaps interface will likely need a bit of finessing but I'm happy to work that out once we get there.

@fitzgen
Copy link
Member Author

fitzgen commented Jun 16, 2020

Thanks for the update @cfallin!

FYI we now have test stackmaps support in filetests now too, so that should hopefully make testing in-tree a little easier for you:

The stack maps interfaces definitely need a little finessing (one example off the top of my head would be to have "semantic" methods rather than just exposing the inner bit map directly and expecting callers to figure out how to interpret that; also I suspect we can do better than iterating over every word in the frame and have an iterator over only the live refs instead).

As long as everything remains SP-relative, then I think Wasmtime should be fine (getting SP portably and reliably is much easier than getting the CFA with libunwind).

cfallin added a commit to cfallin/wasmtime that referenced this issue Jul 15, 2020
With bytecodealliance#1852, we now have support for reference types in the new backend
framework generally, and on aarch64 in particular. This PR removes the
test-ignore directive for reftypes tests on this platform.

Closes bytecodealliance#1886.
cfallin added a commit to cfallin/wasmtime that referenced this issue Jul 15, 2020
With bytecodealliance#1852, we now have support for reference types in the new backend
framework generally, and on aarch64 in particular. This PR removes the
test-ignore directive for reftypes tests on this platform.

Closes bytecodealliance#1886.
@cfallin
Copy link
Member

cfallin commented Nov 13, 2020

Fixed by #2410.

@cfallin cfallin closed this as completed Nov 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wasmtime Issues about wasmtime that don't fall into another label
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants