Skip to content
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

Closed
kripken opened this issue Mar 31, 2021 · 2 comments
Closed

Type of br_if should be the target's type, not the value #3767

kripken opened this issue Mar 31, 2021 · 2 comments

Comments

@kripken
Copy link
Member

kripken commented Mar 31, 2021

(block $target (result ..type..)
  (br_if $target
    (..value..)
    (..condition..)
  )
)

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.

kripken added a commit that referenced this issue Apr 6, 2021
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.
@aheejin
Copy link
Member

aheejin commented Apr 7, 2021

I agree; I encountered this problem in Jan 2020 and tried to fix it by giving a type every time we make br_if, but it was a lot harder than giving a type local.tee. Giving every makeBreak a type was not sufficient; there were other passes that changed/gave a type to br_if, such as RemoveUnusedBrs. Making what we're already doing correct sounds good to me.

@tlively
Copy link
Member

tlively commented Mar 5, 2025

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.

@tlively tlively closed this as completed Mar 5, 2025
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

No branches or pull requests

3 participants