diff options
author | Alon Zakai <azakai@google.com> | 2024-09-24 16:15:06 -0700 |
---|---|---|
committer | GitHub <noreply@github.com> | 2024-09-24 16:15:06 -0700 |
commit | ccef354cc8c0379e91b4dffb365fc69f616d6e25 (patch) | |
tree | 21a4c7d7ed3df24696a9bab7b92cace4bed45354 /src/compiler-support.h | |
parent | 4d906204ebd3ad88a48350f008c7b72a0844e1da (diff) | |
download | binaryen-ccef354cc8c0379e91b4dffb365fc69f616d6e25.tar.gz binaryen-ccef354cc8c0379e91b4dffb365fc69f616d6e25.tar.bz2 binaryen-ccef354cc8c0379e91b4dffb365fc69f616d6e25.zip |
[NFC-ish] Avoid repeated ReFinalize etc. when inlining (#6967)
We may inline multiple times into a single function. Previously, if we did so, we
did the "fixups" such as ReFinalize and non-nullable local fixes once per such
inlining. But that is wasteful as each ReFinalize etc. scans the whole function,
and could be done after we copy all the code from all the inlinings, which is
what this PR does: it splits doInlining() into one function that inlines code and
one that does the updates after, and the update is done after all inlinings.
This turns out to be very important, a 5x speedup on two large real-world wasm
files I am looking at. The reason is that we actually inline more than once in
half the cases, and sometimes far more - in one case we inline over 1,000
times into a function! (and ReFinalized 1,000 times too many)
This is practically NFC, but it turns out that there are some tiny noticeable
differences between running ReFinalize once at the end vs. once after each
inlining. These differences are not really functional or observable in the
behavior of the code, and optimizations would remove them anyhow, but
they are noticeable in two tests here. The changes to tests are, in order:
* Different block names, just because the counter we use sees more things.
* In a testcase with unreachable code, we inline twice into a function, and
the first inlining brings in an unreachable, and ReFinalizing early will lead
to it propagating differently than if we wait to ReFinalize. (It actually leads
to another cycle of inlining in that case, as a fluke.)
Diffstat (limited to 'src/compiler-support.h')
0 files changed, 0 insertions, 0 deletions