diff options
author | Alon Zakai <azakai@google.com> | 2024-05-15 17:00:54 -0700 |
---|---|---|
committer | GitHub <noreply@github.com> | 2024-05-16 00:00:54 +0000 |
commit | e5f2edf4bedb1ab842c2f7ac0dfd58d73e26df7d (patch) | |
tree | 258946ed4f722057af16ae640784b7029a1ed62c /src/ir/table-utils.h | |
parent | 268feb9d77b66d60649682d62a93baa3daadd143 (diff) | |
download | binaryen-e5f2edf4bedb1ab842c2f7ac0dfd58d73e26df7d.tar.gz binaryen-e5f2edf4bedb1ab842c2f7ac0dfd58d73e26df7d.tar.bz2 binaryen-e5f2edf4bedb1ab842c2f7ac0dfd58d73e26df7d.zip |
Fix binary emitting of br_if with a refined value by emitting a cast (#6510)
This makes us compliant with the wasm spec by adding a cast: we use the refined
type for br_if fallthrough values, and the wasm spec uses the branch target. If the
two differ, we add a cast after the br_if to make things match.
Alternatively we could match the wasm spec's typing in our IR, but we hope the wasm
spec will improve here, and so this is will only be temporary in that case. Even if not,
this is useful because by using the most refined type in the IR we optimize in the best
way possible, and only suffer when we emit fixups in the binary, but in practice those
cases are very rare: br_if is almost always dropped rather than used, in real-world
code (except for fuzz cases and exploits).
We check carefully when a br_if value is actually used (and not dropped) and its type
actually differs, and it does not already have a cast. The last condition ensures that
we do not keep adding casts over repeated roundtripping.
Diffstat (limited to 'src/ir/table-utils.h')
0 files changed, 0 insertions, 0 deletions