wasm-gc: Improve precision of alias-checking for structure loads/stores
Categories
(Core :: JavaScript: WebAssembly, enhancement, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox145 | --- | fixed |
People
(Reporter: jseward, Assigned: jseward)
References
(Blocks 2 open bugs)
Details
Attachments
(2 files)
|
8.10 KB,
patch
|
Details | Diff | Splinter Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review |
At the moment, our alias analysis for struct loads/stores only differentiates
between the in-line data area, the out-line data area and the place where the
IL->OOL pointer is stored. That means any structure store invalidates
potential CSEs from other structure loads and severely limits the extent to
which structure loads can participate in GVN and LICM.
For example (at the MIR level),
x1 = struct.get ptr1 field#0
struct.set ptr2 field#42 <value>
x2 = struct.get ptr1 field#0
x3 = x1 + x2
the two struct.gets won't get commoned up even though the intervening
struct.set obviously can't alias them.
Additionally, quite a few MIR nodes have the default aliases-everything
AliasSet, even when this is overkill. In particular MWasmParameter is like
that, which presumably means that any use of MWasmParameter invalidates
potential CSEs from all preceding MIR nodes that read memory. We should fix
that too.
| Assignee | ||
Updated•2 months ago
|
| Assignee | ||
Comment 1•2 months ago
|
||
(In reply to Julian Seward [:jseward] from comment #0)
AliasSet, even when this is overkill. In particular MWasmParameter is like
that, which presumably means that any use of MWasmParameter invalidates
potential CSEs from all preceding MIR nodes that read memory.
This claim is incorrect: MWasmParameter nodes are never moved away from
the start of entry block. So aliasing issues between them and other nodes
are a non-problem.
| Assignee | ||
Comment 2•2 months ago
|
||
WIP. First version that doesn't cause stuff (JS3/*-wasm) to crash.
| Assignee | ||
Comment 3•2 months ago
|
||
This improves alias checking for wasm wasm struct loads/stores, and has some
ridealong cleanups for other wasm alias-set markings.
-
new method MWasmLoadField::mightAlias, TypesMightBeRelatedByInheritance,
which add some better checks for struct aliasing -
ridealongs:
- MWasmLoadField: set movable if there's no trap-site info
- MWasmLoadField::congruentTo: tidy up (no functional change)
-
ridealongs: MWasmNeg, MWasmStackArg WasmRegisterResult
WasmFloatRegisterResult WasmBuiltinFloatRegisterResult WasmRegister64Result
MWasmRefAsNonNull WasmRefCastAbstract WasmRefCastConcrete:
add missing empty-alias-set annotations, as detected during testing -
ridealong: MIROps.yaml: WasmBoundsCheckRange32: add missing
alias_setof
none and missingguardmarking (the latter an outright bug)
| Assignee | ||
Comment 4•2 months ago
|
||
Perf effects for the patch in comment 3 (Intel Tiger Lake, best of 10 runs):
before after
cycles:u cycles:u improvement
j2cl-box2d-w 4,783,244,656 4,702,389,288 +1.7%
Df-complex-w 75,419,255,753 75,351,208,857 +0.1%
Df-todomvc-w 24,013,916,189 23,959,147,626 +0.2%
Ko-compose-w 80,062,108,322 80,146,126,481 -0.1%
| Assignee | ||
Comment 5•2 months ago
|
||
Remeasured. Is worth around 2% for j2cl-box2d and is a wash for
the other three. Best of 10 runs:
Total Score:
basis after
j2cl-box2d 157.27 160.51
Df-todomvc 23.35 23.47
Ko-compose 3.97 3.99
Df-complex 4.29 4.30
cycles:u, millions
basis after
j2cl-box2d 4,751 4,660
Df-todomvc 23,962 23,939
Ko-compose 79,127 79,049
Df-complex 74,799 74,934
instructions:u, millions
basis after
j2cl-box2d 11,620 11,452
Df-todomvc 29,171 29,151
Ko-compose 115,081 114,969
Df-complex 107,311 107,400
L1-dcache-load-misses:u, millions
basis after
j2cl-box2d 196 195
Df-todomvc 592 594
Ko-compose 1,859 1,863
Df-complex 1,655 1,651
Updated•2 months ago
|
Comment 7•2 months ago
|
||
| bugherder | ||
Updated•1 month ago
|
Description
•