-
Notifications
You must be signed in to change notification settings - Fork 829
Complete the support for try_table. #6814
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
Changes from 9 commits
0f0f5a5
fd6eda4
4f07f18
6868ba1
cb49cbb
485914a
0f4eb1a
70f36df
4c752b3
202bc17
7c14456
515b6ae
40da584
d200d06
25d5af9
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -473,6 +473,12 @@ struct TagLocation { | |||||
| } | ||||||
| }; | ||||||
|
|
||||||
| // The location of an exnref materialized by a catch_ref or catch_all_ref clause | ||||||
| // of a try_table. | ||||||
|
||||||
| // of a try_table. | |
| // of a try_table. No data is stored here (exnrefs contain a stack at runtime, but we don't track that), so this is the same as NullLocation in a way: we just need *a* source of contents for places that receive an exnref. |
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's been a while since I read GUFA code so my understanding is bad, but why are all exnrefs treated the same? All nulls are actually the same value and can be used interchangeably, but each exnref contains a different payload and tag, no?
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.
Isn't the payload separate from the exnref? When we catch with an exnref we jump to a block that gets the payload as multivalues + an exnref at the end IIUC.
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.
GUFA doesn't do any abstract interpretation, AFAICT. It only tracks specific literals, and unknown things of certain types. So all unknown (ref exn) are the same anyway.
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.
exnref conceptually contains the payload, even though it is opaque, no? I think we can treat it in the same way we treat externref or anyref, given that they also contain something opaque. How do we treat them in GUFA? Do we treat all of them as the same literal?
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.
In the new EH (exnref) scheme, when we rethrow an exnref using throw_ref, we rethrow the whole package, including a tag and a payload. So exnref contains both.
Oh, I didn't realize that. So when we catch, we are sending the payload as values, and also sending it wrapped in the
exnrefobject (which also has the stack and tag id)? So we send it both wrapped and unwrapped?
No I think, at least conceptually (because the actual implementation in the engines can differ), we just send a package (=exnref). And when caught, depending on the kind of catch clauses, we provide the exnref as is or extract values from it and provide the values.
I think we can treat it in the same way we treat externref or anyref, given that they also contain something opaque.
Makes sense, yeah. That is basically what the code does. E.g. if an import returns an anyref, then we know nothing about it but the type, so we fill that
ResultLocation(result of a function) withaddRoot, which just sets it to an unknown value of that type. The code here does the same, but we do need a Location to read the exnref from (it isn't aResultLocationor anything else we have, yet), so we add that as well.
Still not sure why we need a separate location kind, given that externref/anyref doesn't have any. exnref here is just a return value from a block, so it can be treated as such, no? Do we need a separate Location kind for every kind of block return value? Or it can be treated the same way as a return value of a br, because it sends the info as the block return value.
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.
The issue is, where does the block return value receive the value from? anyref arrives from e.g. a function result, which we already have a Location type for. But here we are not just adding a new type but also a new control flow construct that sends that value.
But maybe we could instead add a root on the target of the branch, though, is that what you mean? I suppose there is just one such target, and we know exactly what it is. I think that would be safe and correct to do here (that location can't be marked as a root for any other reason), but it does seem a little cleaner to me to keep the code as it is, since the branch target is not conceptually a "root" (e.g. it may receive values from other branches than this, so it needs to combine them all. We do know that this unknown value will "win", but conceptually we are still combining there).
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.
Hmm I see. Then I guess even though all exnrefs are treated as the same constant it wouldn't matter in GUFA because it doesn't do anything with constants, right?
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.
Yeah, we just move constants around, but don't do anything with the values otherwise. So this should be ok as is, I think.
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.
Hmm I see. Then I guess even though all
exnrefs are treated as the same constant it wouldn't matter in GUFA because it doesn't do anything with constants, right?
They're not treated like the same constant. They're all treated as some unknown value of type (ref exn). GUFA makes a difference between actual constants and unknown values of some type. If we did register them as the same constant, that would be bad, as GUFA would then propagate that constant at all destinations.
Uh oh!
There was an error while loading. Please reload this page.