-
Notifications
You must be signed in to change notification settings - Fork 760
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
Type of br_if should be the target's type, not the value #3767
Comments
We give br_if a too specific type: #3767 This is only noticeable with GC, and in rare cases where the type of br_if is actually used - which realistically it never is, so really just fuzzer testcases.
I agree; I encountered this problem in Jan 2020 and tried to fix it by giving a type every time we make |
We now work around this in the binary writer by inserting casts after branches as necessary, so I'll go ahead and close this. We may need to revisit this strategy in the future, for example if we introduce new references that cannot be cast (continuation references are possibly already in this category), but we can discuss that in follow-on issues. |
The type of the
br_if
should be the type of$target
, not of..value..
. Binaryen gets this wrong while v8, wabt, and wasp get it right.In practice the return value of
br_if
is not that useful - I've only ever seen it dropped, except in fuzzer-generated code. That's probably why this never came up. (The fuzzer found it now.)For that reason I'm not sure it's worth fixing. Another reason is that this is parallel to WebAssembly/gc#201 where there is discussion on making
local.tee
's type that of the value and not the local, which is basically the same issue. If we make that change then Binaryen is already doing the right thing.The text was updated successfully, but these errors were encountered: