-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Conversation
70038a7
to
692a7a6
Compare
Subscribe to Label Actioncc @peterhuene
This issue or pull request has been labeled: "wasmtime:api"
Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
There was a problem hiding this 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?
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
My thinking was that, because no toolchains emit Do you think it is worth the effort? |
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! |
692a7a6
to
b04bd00
Compare
@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! |
👍 |
We use libcalls to implement these -- unlike
table.{get,set}
, for which wecreate inline JIT fast paths -- because no known toolchain actually uses
externref globals.
Part of #929