Support direct call inlining in Ion
Categories
(Core :: JavaScript: WebAssembly, enhancement, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox130 | --- | fixed |
People
(Reporter: jseward, Assigned: jseward)
References
Details
Attachments
(6 files, 9 obsolete files)
|
10.00 KB,
application/octet-stream
|
Details | |
|
124.71 KB,
patch
|
Details | Diff | Splinter Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review |
Bug 1864209 tracks experimentation with a purely-MIR-level inliner for use
with wasm. That scheme seems difficult to make work reliably, so this bug
tracks experimentation of an inliner for wasm structured in the same way that
inlining is done in Warp; that is, each callee to be inlined is generated
directly from wasm bytecode every time it is needed.
Attached is an initial patch that does this, for direct, non-catchable calls
only. It is very much WIP and contains a lot of leftover junk from the
bug 1864209 attempt that can now be removed. The patch will inline
arbitrarily deep, stopping only when a callee has more than 24 bytes of
bytecode. Multi-value returns don't work yet.
| Assignee | ||
Comment 1•2 years ago
|
||
| Assignee | ||
Comment 2•2 years ago
|
||
A simple test case.
| Assignee | ||
Comment 3•2 years ago
|
||
Greatly cleaned up, and now handles args that would have been passed
on the stack. Multi-value returns still don't work though.
| Assignee | ||
Comment 4•2 years ago
|
||
Able to inline any call-direct, non-catchable call, providing the callee's
bytecode is available. This includes calls to functions requiring args to be
passed on the stack (eg x86_32) and calls to functions that return multiple
values.
| Assignee | ||
Comment 5•2 years ago
|
||
Test cases for the comment 4 implementation.
| Assignee | ||
Comment 6•2 years ago
|
||
A very minor cleanup of the comment 4 patch. Can process all of the
comment 5 test cases correctly, at least on x86_{32,64}-linux, although you'll
need to run with IONFLAGS=dump-mir-expr to see that. Applies against m-c
684483:5d6699b34edc.
Updated•2 years ago
|
| Assignee | ||
Comment 7•2 years ago
|
||
Now with significantly fewer bugs.
Also, IONFLAGS=wasm-inlining now produces a 1-line summary
of inlining activity for each (top-level) function processed.
| Assignee | ||
Comment 8•2 years ago
|
||
Now with loop depths handled properly. This fixes assertion
failures to do with phi nodes mysteriously disappearing.
| Assignee | ||
Comment 9•2 years ago
|
||
Now doesn't cause crashing in the presence of return calls, and has a space
leak fix. Pretty much all of the jit_tests wasm tests pass now, and large
files (clang.wasm, dart.test.wasm, etc) can be processed. Is usable for
playing around assessing the perf effects of inlining (direct) calls. The
only major missing functionality now is that calls inside try blocks are not
(yet) inlined.
| Assignee | ||
Comment 10•2 years ago
|
||
Rebased to m-c 691458:33d47d05c368 (9 Jan 2024).
| Assignee | ||
Comment 11•2 years ago
|
||
With per-function-stack state split out of FunctionCompiler into new class
FunctionStackState.
Updated•1 year ago
|
Comment 12•1 year ago
|
||
Once we have bug 1885363 and bug 1876155 landed, I believe we could update this could to be in a state that's landable. I'm renaming this bug to move the focus from experimentation to something we could land.
Comment 13•1 year ago
|
||
- Move declareFuncExported to FuncDesc
- Move addDefinedFunc/addImportedFunc to ModuleMetadata
- Make sure we serialize everything
- Move branch hint parsing information to BranchHintCollection
- Re-order all of the fields on CodeMetada to be grouped logically and roughly follow initialization order
- namePayload doesn't need to be mutable after we made CodeMetadata be owned by ModuleMetadata
Comment 14•1 year ago
|
||
We need bytecode() for inlining, move it to CodeMetadata
instead of Code.
Depends on D216750
Comment 15•1 year ago
|
||
This commit adds direct call inlining to Ion when we're lazy tiering,
using simple heuristcs.
The overall design is similar to how JS does inlining with Warp. When
we see a call instruction we want to inline, we recursively create a
new FunctionCompiler and have that generate MIR for the inlined callee
function.
The following things needed to be changed:
- FunctionCompiler gains a notion of a 'callerCompiler' which tracks
the outer caller function when inlined. - The top-level function in a compilation now holds alive a set of
jit::CompileInfo for all the inlined functions. This is because
this data structure is pointed to by MIR and so it must live until
the MIR is compiled. - FunctionCompiler::initInlined is added which sets up the params to
come from a caller, instead of using the MWasmABIArg defs. - FunctionCompiler::returnValues is changed to accumulate the returns
when inlining, instead of using MWasmReturn instructions. - FunctionCompiler::finishInlinedCallDirect is added to bind the pending
returns to a join block. - A shouldInlineCallDirect heuristic is added, partially controlled by
new prefs. This is naive and could use some tuning. - Tail calls are not supported in the inlined function, but we have no
good way to rule them out, so we just crash for now. The next commit
fixes this.
There is a bit of redundant state on the stack of FunctionCompiler's
which could be factored out into some sort of 'SharedFunctionCompiler'.
This commit does not do that, but a future commit could.
Depends on D216752
Comment 16•1 year ago
|
||
Add a per-funcdef FeatureUsage tracker that we can use when lazy
tiering to prevent inlining into a tail call. This lets us remove
the crash and replace it with an assert.
Depends on D216753
Comment 17•1 year ago
|
||
Comment 18•1 year ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/7a6190776114
https://hg.mozilla.org/mozilla-central/rev/e6767af87508
https://hg.mozilla.org/mozilla-central/rev/a94fa14b655e
https://hg.mozilla.org/mozilla-central/rev/48e881f47b12
https://hg.mozilla.org/mozilla-central/rev/bde59718573f
Description
•