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: Implement global.{get,set} for externref globals #1969

Merged
merged 2 commits into from
Jul 2, 2020

Conversation

fitzgen
Copy link
Member

@fitzgen fitzgen commented Jul 2, 2020

We use libcalls to implement these -- unlike table.{get,set}, for which we
create inline JIT fast paths -- because no known toolchain actually uses
externref globals.

Part of #929

@fitzgen fitzgen requested a review from alexcrichton July 2, 2020 17:45
@github-actions github-actions bot added the wasmtime:api Related to the API of the `wasmtime` crate itself label Jul 2, 2020
@github-actions
Copy link

github-actions bot commented Jul 2, 2020

Subscribe to Label Action

cc @peterhuene

This issue or pull request has been labeled: "wasmtime:api"

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

  • peterhuene: wasmtime:api

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

Learn more.

Copy link
Member

@alexcrichton alexcrichton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, and even more tests passing!

I think it's fine that these aren't fast right-out-the-gate, but I wonder if perhaps a little refactoring in the code generator could make this PR even smaller and also faster at the same time? It seems that table.get and global.get are basically the same codegen after they determine the address they're loading from. Similarly table.set and global.set are the same once they've got the address.

Do you think it'd be possible to refactor the translation of table.set and table.get to be shared with these instructions? Ideally just a small portion of it would be chopped off to go elsewhere (which would take in an address) and then the instructions would all otherwise codegen exactly the same way.

If this looks harder than I expect though it seems fine to have out-of-line intrinsics for now and optimize later as necessary.

Other than that, could you also add some API tests which exercises get/set for funcref/anyref globals? It looks like there's get for externref but at the wasmtime API layer I don't think there's much other coverage?

tests/all/gc.rs Show resolved Hide resolved
tests/all/gc.rs Show resolved Hide resolved
We use libcalls to implement these -- unlike `table.{get,set}`, for which we
create inline JIT fast paths -- because no known toolchain actually uses
externref globals.

Part of bytecodealliance#929
@fitzgen
Copy link
Member Author

fitzgen commented Jul 2, 2020

My thinking was that, because no toolchains emit externref globals, it wasn't worth the effort to make the inline JIT fast path generation code more generic. This would also require some cranelift-wasm interface changes.

Do you think it is worth the effort?

@alexcrichton
Copy link
Member

Nah I don't think it's worth it if it requires larger changes. I just thought that it might be simple to implement today if the code was extracted from table.{get,set}, but if that's not the case then this seems fine to me!

@fitzgen
Copy link
Member Author

fitzgen commented Jul 2, 2020

@alexcrichton good call on adding tests for the global API with funcref and externref, that actually required a bit of plumbing in the trampoline module. Do you want to take a look at the new commit? Thanks!

@fitzgen fitzgen requested a review from alexcrichton July 2, 2020 20:41
@alexcrichton
Copy link
Member

👍

@alexcrichton alexcrichton merged commit bffd54c into bytecodealliance:main Jul 2, 2020
@fitzgen fitzgen deleted the externref-globals branch July 2, 2020 21:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wasmtime:api Related to the API of the `wasmtime` crate itself
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants