diff options
author | Alon Zakai <azakai@google.com> | 2023-06-13 12:10:18 -0700 |
---|---|---|
committer | GitHub <noreply@github.com> | 2023-06-13 12:10:18 -0700 |
commit | 00211a90878cf0f37fbfb124332c4abc9863032b (patch) | |
tree | f7e460fe8eeebebc434d8e349baa551abbbe1207 /test/lit/help/wasm2js.test | |
parent | 491f596fd13cdba5b4230ebf5a5c076bcafdab6f (diff) | |
download | binaryen-00211a90878cf0f37fbfb124332c4abc9863032b.tar.gz binaryen-00211a90878cf0f37fbfb124332c4abc9863032b.tar.bz2 binaryen-00211a90878cf0f37fbfb124332c4abc9863032b.zip |
EffectAnalyzer: Assume we execute the two things whose effects we compare (#5764)
EffectAnalyzer::canReorder/invalidate now assume that the things from whom we
generated the effects both execute (or, rather, that if the first of them doesn't
transfer control flow then they execute). If they both execute then we can do more work
in TrapsNeverHappen mode, since we can then reorder this for example:
(global.set ..)
(i32.load ..)
The load may trap, but in TNH mode we assume it won't. So we can reorder those
two. However, if they did not both execute then we could be in this situation:
(global.set ..)
(br_if ..)
(i32.load)
Reordering the load and the set here would be invalid, because we could make the
load execute when it didn't execute before, and it could now start to actually
trap at runtime.
This new assumption seems obvious, since we don't compare the effects of
things unless they are adjacent and with no control flow between them - otherwise,
why compare them? To be sure, I manually reviewed every single use of
EffectAnalyzer::canReorder/invalidate in the entire codebase.
I've also been fuzzing this for several days (hundreds of thousands of iterations),
and have not seen any problem.
This was motivated by seeing that #5744 should be able to do more work in TNH
mode, but it wasn't. New tests show the benefits there in OptimizeCasts as well
as in SimplifyLocals.
Diffstat (limited to 'test/lit/help/wasm2js.test')
0 files changed, 0 insertions, 0 deletions