Skip to content

Serialize side table and integrate verify #758

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

Merged
merged 33 commits into from
Mar 3, 2025

Conversation

zhouwfang
Copy link
Contributor

@zhouwfang zhouwfang commented Feb 23, 2025

#46

Copy link
Member

@ia0 ia0 left a comment

Choose a reason for hiding this comment

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

Thanks! I think the issues come from the fact that the side-table format is not correct yet.

@zhouwfang zhouwfang force-pushed the serialize-side-table branch from edd20af to 0e701b9 Compare February 27, 2025 04:15
@zhouwfang zhouwfang requested a review from ia0 February 28, 2025 04:23
@zhouwfang
Copy link
Contributor Author

zhouwfang commented Feb 28, 2025

Now that valid.rs becomes generic over ValidMode, I wonder how I could print debugging logs for generic objects. For example, I'm not sure how to print the next branch table. I added Debug at some places, but there still seems something missing.

@ia0
Copy link
Member

ia0 commented Feb 28, 2025

Now that valid.rs becomes generic over ValidMode, I wonder how I could print debugging logs for generic objects.

I've pushed a commit for that (called debug). For generic contexts you need the Debug bound on the associated types (not just on the final types used for those associated types in the trait implementations).

source.parser == target.parser
&& source.result == target.result
&& source.branch_table == target.branch_table
&& source.stack <= target.stack,
Copy link
Contributor Author

@zhouwfang zhouwfang Mar 2, 2025

Choose a reason for hiding this comment

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

@ia0 This is a necessary condition of the logic in pop_cnt(). The actual equivalent condition should be source.stack == target.stack || (pop_cnt == 0 && source.stack < target.stack), but it does not seem straightforward to obtain pop_cnt wherever stitch_branch() is called.

Copy link
Contributor Author

@zhouwfang zhouwfang Mar 2, 2025

Choose a reason for hiding this comment

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

Update: we can store pop_cnt as Option<usize> in SideTableBranch. WDYT?

Copy link
Member

Choose a reason for hiding this comment

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

I'll need to look into this when I get time. I think the whole situation around pop_cnt feels wrong, but maybe I'm missing something. I've added some TODOs to not lose track of this. This should not block this PR.

@zhouwfang
Copy link
Contributor Author

zhouwfang commented Mar 2, 2025

The only test that fails in the test suite now is the huge br_table because of "index of MetadataEntry overflow" (the index is 97252). Do we want to change it to u32?

I suspect the error in ./scripts/hwci.sh is due to the same reason (but I'm not sure how to check that).

@zhouwfang zhouwfang requested review from ia0 and removed request for ia0 March 2, 2025 21:22
@zhouwfang zhouwfang changed the title Serialize side table Serialize side table and integrate verify Mar 2, 2025
@zhouwfang zhouwfang changed the title Serialize side table and integrate verify Serialize side table and integrate verify Mar 2, 2025
ia0
ia0 previously approved these changes Mar 3, 2025
Copy link
Member

@ia0 ia0 left a comment

Choose a reason for hiding this comment

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

Thanks! That's a huge step, but I'm not convinced about the pop_cnt story yet. I'll need to look into it. Ideally we should do some differential fuzzing, I don't trust the test suite to provide good coverage.

Comment on lines 176 to 177
let mut parser = unsafe { Parser::new(self.binary) };
parser.parse_side_table().unwrap();
Copy link
Member

Choose a reason for hiding this comment

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

This is costly. I'm pushing an optimize Module::func() commit to fix it. The idea is to have self.binary start at the same place as module_start in Context::check_module().

source.parser == target.parser
&& source.result == target.result
&& source.branch_table == target.branch_table
&& source.stack <= target.stack,
Copy link
Member

Choose a reason for hiding this comment

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

I'll need to look into this when I get time. I think the whole situation around pop_cnt feels wrong, but maybe I'm missing something. I've added some TODOs to not lose track of this. This should not block this PR.

@ia0
Copy link
Member

ia0 commented Mar 3, 2025

The only test that fails in the test suite now is the huge br_table because of "index of MetadataEntry overflow" (the index is 97252). Do we want to change it to u32?

I suspect the error in ./scripts/hwci.sh is due to the same reason (but I'm not sure how to check that).

I'm not sure we want to support such corner-cases. For now I'm ignoring all 149 tests in br_table, but maybe some of them we shouldn't. We can deal with that later.

If hwci is still failing, I'll take a look and work around it to merge. It might be because of the pop_cnt story which might be wrong and is not caught by the test suite.

@ia0
Copy link
Member

ia0 commented Mar 3, 2025

Yes, hwci is still failing, I'm disabling it in this branch.

@ia0 ia0 force-pushed the serialize-side-table branch from c62d1cd to 911b5ae Compare March 3, 2025 10:55
@ia0 ia0 merged commit 188766a into google:dev/fast-interp Mar 3, 2025
19 checks passed
Comment on lines +1152 to +1153
// TODO(dev/fast-interp): Figure out why we can't simply source.stack - target.stack and
// document it.
Copy link
Contributor Author

@zhouwfang zhouwfang Mar 4, 2025

Choose a reason for hiding this comment

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

@ia0 I thought we shouldn't always expect source.stack to be >= target.stack. One example is the as-if-cond in br_if.wast. In pop_cnt() for Else, we have source=SideTableBranch { parser: [65, 2, 5, 65, 3, 11, 11, 11], branch_table: 1, stack: 0, result: 0 }, target=SideTableBranch { parser: [65, 3, 11, 11, 11], branch_table: 3, stack: 1, result: 1 }.

@zhouwfang
Copy link
Contributor Author

zhouwfang commented Mar 4, 2025

The only test that fails in the test suite now is the huge br_table because of "index of MetadataEntry overflow" (the index is 97252). Do we want to change it to u32?
I suspect the error in ./scripts/hwci.sh is due to the same reason (but I'm not sure how to check that).

I'm not sure we want to support such corner-cases. For now I'm ignoring all 149 tests in br_table, but maybe some of them we shouldn't. We can deal with that later.

If hwci is still failing, I'll take a look and work around it to merge. It might be because of the pop_cnt story which might be wrong and is not caught by the test suite.

I had checked br_table.wast throughly, and large is only function that fails due to the u16 overflow (after I commented out this function, the test suite passes).

pop_cnt should be correct for hwci because I had completed its creation in valid.rs and usage in exec.rs long time ago, and there has been no issue with hwci. This CL does not make any change on pop_cnt itself. The hwci error should be due to u16 overflow.
Proof: in zhouwfang#10, I only added a commit on top of my last one in this PR that removes source.stack <= target.stack in stitch_branch(), which is the only code that is related to pop_cnt in this PR. But the hwci error remains.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants