Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 599f35b6714354280079b1e8dc68ebea70e731eb
https://github.com/WebKit/WebKit/commit/599f35b6714354280079b1e8dc68ebea70e731eb
Author: Keith Miller <[email protected]>
Date: 2026-04-10 (Fri, 10 Apr 2026)
Changed paths:
M Source/JavaScriptCore/llint/InPlaceInterpreter.asm
M Source/JavaScriptCore/llint/InPlaceInterpreter64.asm
M Source/JavaScriptCore/offlineasm/parser.rb
M Source/JavaScriptCore/wasm/WasmBBQJIT.cpp
M Source/JavaScriptCore/wasm/WasmCallingConvention.h
M Source/JavaScriptCore/wasm/WasmOMGIRGenerator.cpp
M Source/JavaScriptCore/wasm/WasmOperations.cpp
M Source/JavaScriptCore/wasm/js/JSToWasm.cpp
Log Message:
-----------
[JSC] Wasm stack results should match arguments
https://bugs.webkit.org/show_bug.cgi?id=311838
rdar://174428575
Reviewed by Yusuke Suzuki.
Rework how stack results are read after wasm calls so that they match
the location of equivalent arguments. This is preliminary work so tail
calls don't require whole-module analysis to determine where to restore
instance/memory pinned registers. In that world there may or may not be
an injected frame between any caller and callee shift the result
location by some constant. This makes the current calling convention
difficult to maintain as we don't know exactly which of the two offsets
to find results.
In this patch we go back to the original multi-value calling convention,
where arguments and results match. Any caller should copy stack results
before restoring SP.
Extracting the results differs based on the caller. For BBQ/IPInt we
move the stack results to their canonical location. In OMG,
createCallPatchpoint stack return value constraints use WarmAny so B3
can place results whereever it wants as they have to be copied anyway.
Due to an outstanding issue when graph coloring is enabled where we run
out of colors (aka registers) we use still use the argument's stack slot.
JSToWasm makes space for registers below the callee frame and fills the
register results there then calls to the appropriate operation to build
the result Array.
Old Wasm calling convention (before this patch):
Stack results were offset to the top of the area, so resultK was NOT at
the same address as argK:
+----------------------------+
| result1 | arg3 | <- resultStackOffset = headerSize +
aligned - resultSize
+----------------------------+
| result0 | arg2 | <- results shifted, don't align with args
+----------------------------+
| | arg1 |
+----------------------------+
| | arg0 | <- argStackOffset = headerSize
+----------------------------+
| instance |
+----------------------------+
| wasmCallee |
+----------------------------+
| returnAddress |
+----------------------------+
| callerFrame | <- cfr
+----------------------------+
New Wasm calling convention (this patch):
Arguments and results share the same stack addresses. argK and resultK
occupy the same slot. The area is sized to max(args, results):
+----------------------------+ higher addresses
| ...... | |
+----------------------------+ |
| arg/result N | |
+----------------------------+ |
| ... | |
+----------------------------+ |
| arg/result 1 | |
+----------------------------+ |
| arg/result 0 | <- headerSize (args & results start here)
+----------------------------+ v lower addresses
| instance |
+----------------------------+
| wasmCallee |
+----------------------------+
| returnAddress |
+----------------------------+
| callerFrame | <- cfr
+----------------------------+
The Nth stack argument and the Nth stack result are at the exact same
address.
Also, this broke internal builds since a non-ASCII character was added
to the IPInt .asm file. Add a check we don't make the same mistake again.
No new tests, no behavior change, covered by existing tests.
Canonical link: https://commits.webkit.org/310952@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
