-
Notifications
You must be signed in to change notification settings - Fork 793
[reference-types] remove single table restriction in IR #3517
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
Conversation
16a7a4b
to
657e727
Compare
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.
Thank you! Haven't read all the PR yet, but the very initial comments:
I don't think we have a test case that uses multiple tables and call_indirect
s with a table index yet. Can we have one? Maybe multi-table.wast or something in test/ directory. You can run ./auto_update_tests.py to update other files after adding it.
(Also we would need tests for other added parts such as tests for the added C API)
Thanks, @aheejin.
Right, I started adding tests today. Hopefully I can push some by tomorrow. |
this will allow adding further support for reference-types
46b8b17
to
c378d6f
Compare
I don't think we can test modules with multiple tables yet, because in this PR I tried to keep it minimal and not implement the new changes from the spec as much as possible. For instance, we cannot parse an My plan was to get this PR reviewed and merged, to make sure that everything is working as before and I haven't missed anything. And then, continue with the remaining parts of the reference types spec. |
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.
I didn't review the entire thing yet, but the wasm.h and wasm-delegates-fields.h changes look like the right approach. Thanks for the PR!
Will try to review the rest tomorrow.
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.
I don't think we have a test case that uses multiple tables and
call_indirect
s with a table index yet. Can we have one? Maybe multi-table.wast or something in test/ directory. You can run ./auto_update_tests.py to update other files after adding it.I don't think we can test modules with multiple tables yet, because in this PR I tried to keep it minimal and not implement the new changes from the spec as much as possible. For instance, we cannot parse an
elem
section in wast files that belong to tables with higher indexes. It does parse elems embedded inside atable
declaration, but roundtrip runs fail as the elem section is separated from the table, and is therefore added to table 0. I did add a test/example for the new c apis though.My plan was to get this PR reviewed and merged, to make sure that everything is working as before and I haven't missed anything. And then, continue with the remaining parts of the reference types spec.
Thanks. Sorry I was OOO and I have still read only a fraction of the PR so far; I think this PR is one of the fundamental changes, but the only test additions + changes I see are from metrics, wasm-split (which I don't understand well why they are necessary; I asked questions there), and some table name changes.
I understand it is sometimes hard to add tests for every single part of code changes, especially in this kind of big PRs that change one of the very fundamental assumptions in the code base, so I really appreciate your work! But I still think this kind of big PRs need at least some tests that cover the very backbone of changes, which I think should include wast reading/writing and binary reading/writing. Also I think it is more desirable for a PR to have a smaller change with tests that matches the change, but as I said, I know it is not always easy in this kind of PRs.. 😅
I think maybe we can defer implementations + tests for the new call_indirect
for the next PR, but I still would like to see at least some tests that show basic reading/writing of multiple tables working. Can we add those parts to the PR and maybe defer some other parts of the implementation that are not essential to the reading/writing to the next PR? I think C-API also could have been deferred if you wanted to make this minimal but you already added them so that looks good.
Anyway I'll probably take a more close look within a few days but please don't think me as a blocker for LGTM as long as others are happy with it.
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.
It looks like a lot of code could be simplified by requiring call_indirect
to have a real table name rather than defaulting to the first table if the table name is empty.
@tlively Thanks a lot for the review! I will try to address the points by tomorrow. |
@tlively I think I've addressed most of the review points here (I hope I haven't missed any), except for adding support for multiple tables in the fuzzer. After reading Other than that, please do let me know if you have other comments about this PR. Hopefully we can finalize it very soon! |
Neat, the latest changes look good to me. Can you summarize the C/JS API changes in the change log? Beyond that, I want to just do another review pass over everything and then it should be good! |
src/tools/wasm-ctor-eval.cpp
Outdated
if (tableName.is()) { | ||
return wasm->getTableOrNull(tableName); | ||
} else if (!wasm->tables.empty()) { | ||
return wasm->tables.front().get(); | ||
} |
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.
I think this function can be removed and its use replaced with just wasm->getTableOrNull(tableName)
now that we are assuming that the table name is always present.
src/wasm/wasm-binary.cpp
Outdated
o << U32LEB(0x0); | ||
} else { | ||
o << U32LEB(0x2); |
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.
It would be good to use the enum values here.
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.
Thanks I used constants, although using ?:
made it look a bit ugly! I can try several if
blocks if you prefer. I've seen both styles in wasm-binary.cpp
.
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.
Yes, I think the if
blocks would be better in this case, but I'm going to merge this as-is because it is so big and I don't want it to get out of sync with upstream. If you wouldn't mind fixing this in a follow-up PR, that would be great :)
After those final two comments are addressed, I will be happy to merge this :) |
@tlively Thanks a lot for catching those! I've already started working on the next PR to add a ref type to |
Thanks for your great work on this, @martianboy! |
Yaay! Finally! Thanks again @tlively. :) |
You're welcome :D |
It looks like this change broke a bunch of emscirpten tests. At first glance it looks like any test related to dyanmic linking: e.g.:
|
@sbc100 I will look into this as soon as I can. |
I fixed it in #3560 |
This will remove the single table per module assumption everywhere, and
instead introduces a vector of tables, same as functions, globals, etc.
Support for parsing and writing multiple tables is added and C/JS APIs
have been updated accordingly. A table name argument is also added to
call_indirect.
(Fixes #3512)