-
Notifications
You must be signed in to change notification settings - Fork 21
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
Add val_cnt and pop_cnt in side table #649
Conversation
The hw-host error says |
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! Going through I realized we probably want to store val_cnt
in source branches already since that's an information available at that time. This is particularly relevant in br_label()
.
So I suggest:
- Add
result: usize
toSideTableBranch
which is always zero for target branches and representsval_cnt
for source branches. - Make
branch_source()
takeresult: usize
. - Refactor
br_label()
to match on the label kind before creating the source branch, returning(ResultType, Option<SideTableBranch>)
which is the result of the function and the target branch (if it's a loop). Then create the source branch with the result length, match on the option to stitch or push, and return the result.
Ideally we should |
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.
Ok, I think it should be mostly correct. It'll be easier to debug once we can run the test suite using the side table.
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 tried to look into the tests and actually there are fundamental problems:
- Since I added auto-skipping of unsupported behaviors, we may accidentally pass the test because everything is unsupported due to a bug. I need to fix the tests so that we can distinguish between really unsupported and unsupported by accident. Not completely sure yet how, probably just a counter of skipped tests due to unsupported, but I'd like to find something better.
- We need to be very careful when we call
branch_{source,target}()
because it will save the stack. This matters particularly when we push a label, because we don't want to save the parameters of the label.
Sadly I don't have time at the moment to dig into this. I think the design is not there yet (for example, maybe we actually want to store the "val_cnt/result" in the target branch instead. Maybe it will help with capturing too much of the stack because we know val_cnt
is included.
If you want to continue working on this until I get time to look into again, you can try to experiment on your own and run the test suite to test the invariants you come up with. The more asserts you can write that don't fail in the test suite, the better your understanding of the code will be.
5c1c205
to
cc29418
Compare
With the commit In the meanwhile, I'm printing the side tables for some test cases in the test suite as a sanity check. |
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 mind merging this without thorough review such that you can start using the side table in exec.rs
which is the important part to be able to debug. I think this PR needs a redesign and it's hard to tell unless the side table is actually used during execution. I'll do a proper review once we have everything working end-to-end.
But you can also use the side table in exec.rs
in this PR if you want. As you prefer.
Thanks for the review. I plan to use |
Also self-update at startup for `cargo install` builds, since those lack the host platform.
Verified for 3 examples.
f509e36
to
6a1f2e5
Compare
@ia0 Could you merge |
Note: the side tables are now correct for the examples we discussed. |
crates/interpreter/src/valid.rs
Outdated
@@ -560,7 +585,8 @@ impl<'a, 'm> Expr<'a, 'm> { | |||
Nop => (), | |||
Block(b) => self.push_label(self.blocktype(&b)?, LabelKind::Block)?, | |||
Loop(b) => { | |||
self.push_label(self.blocktype(&b)?, LabelKind::Loop(self.branch_target()))? | |||
let type_ = self.blocktype(&b)?; | |||
self.push_label(type_, LabelKind::Loop(self.branch_target(type_.results.len())))? |
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.
For loop, I'm not sure whether I should use type_.results.len()
(as in other cases) or type_.params.len()
for val_cnt
. But I suspect the latter is correct for the following reason: in exec.rs
, the last arity
values are kept which should be the same as val_cnt
. By the definition of arity
in exec.rs
, the latter is used.
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.
Exactly, it's params.
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.
Let me know if my understanding about the reason why it is different for loop is correct: For loop, we jump to the beginning instead of the end. When we jump to the beginning, we need to look at the params. The result of the loop will be handled by the outer scope of the loop.
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
After thinking more, it may be better to merge this PR first because using |
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.
Sounds good, let's merge this.
crates/interpreter/src/valid.rs
Outdated
@@ -560,7 +585,8 @@ impl<'a, 'm> Expr<'a, 'm> { | |||
Nop => (), | |||
Block(b) => self.push_label(self.blocktype(&b)?, LabelKind::Block)?, | |||
Loop(b) => { | |||
self.push_label(self.blocktype(&b)?, LabelKind::Loop(self.branch_target()))? | |||
let type_ = self.blocktype(&b)?; | |||
self.push_label(type_, LabelKind::Loop(self.branch_target(type_.results.len())))? |
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.
Exactly, it's params.
There was an earlier review in zhouwfang#2.
#46