Branch: refs/heads/webkitglib/2.54
Home: https://github.com/WebKit/WebKit
Commit: bee3709247042124663a14be27e8715957ffbb99
https://github.com/WebKit/WebKit/commit/bee3709247042124663a14be27e8715957ffbb99
Author: Dan Hecht <[email protected]>
Date: 2026-09-02 (Wed, 02 Sep 2026)
Changed paths:
A JSTests/wasm/stress/omg-reduce-strength-select-exception-stackmap.js
M Source/JavaScriptCore/b3/B3ReduceStrength.cpp
M Source/JavaScriptCore/wasm/WasmOMGIRGenerator.cpp
Log Message:
-----------
Cherry-pick [email protected] (db24355101bd).
https://bugs.webkit.org/show_bug.cgi?id=316791
[JSC] Do not clone patchpoints for Wasm calls within a try block
rdar://178657225
https://bugs.webkit.org/show_bug.cgi?id=316791
Reviewed by Yijia Huang.
Similar to throw/rethrow patchpoints, a Wasm OMG call patchpoint inside
a Try block carries an exception-restoration stackmap keyed by its
CallSiteIndex,
so it should not be cloned. If B3 Select specialization (or
B3DuplicateTails)
duplicates them, that leaves two call sites sharing one stackmap even with
potentially differing live-value layouts.
Extend 266643@main to also mark call patchpoints cloningForbidden when
m_tryCatchDepth != 0, and make specializeSelect() bail when a
cloning-forbidden value is in the range it would clone.
Test: JSTests/wasm/stress/omg-reduce-strength-select-exception-stackmap.js
Identifier: [email protected]
Canonical link: https://commits.webkit.org/317695.178@webkitglib/2.54
Commit: 09236187b6514c773084e2d3f962c4b68e8db926
https://github.com/WebKit/WebKit/commit/09236187b6514c773084e2d3f962c4b68e8db926
Author: Dan Hecht <[email protected]>
Date: 2026-09-02 (Wed, 02 Sep 2026)
Changed paths:
A
JSTests/stress/object-allocation-sinking-phase-must-only-move-allocations-if-stack-trace-is-still-valid-closure-rule-promoted-parent.js
A
JSTests/stress/object-allocation-sinking-phase-must-only-move-allocations-if-stack-trace-is-still-valid-closure-rules.js
M Source/JavaScriptCore/dfg/DFGObjectAllocationSinkingPhase.cpp
Log Message:
-----------
Cherry-pick [email protected] (a4e027e916f5).
https://bugs.webkit.org/show_bug.cgi?id=315674
[JSC] Fix Object Allocation Sinking closure rule for allocations within
inlined closure-call and varargs frames
https://bugs.webkit.org/show_bug.cgi?id=315674
rdar://176555185
Reviewed by Yijia Huang.
208291@main added an InlineCallFrame check that demotes candidate
allocations whose origin is a closure-call or varargs inline frame and
whose escape site is in a different frame. The check is necessary
because such an allocation, if sunk to the escape site, would have its
Materialize* node emitted where the frame's closure-call callee
slot or varargs argc slot has been reused by intervening code, causing
subsequent stack walks to potentially dereference garbage.
However, that fix was incomplete in two ways. First, the InlineCallFrame
check ran before the closure rule's worklist ("rule #2"), so it only
inspected the initial candidates. Rule #2 then promoted additional
dependencies to satisfy the closure invariant (a sink candidate stored
into a local allocation, that allocation must also be a sink candidate"),
and any such promoted allocation that would have failed the
InlineCallFrame check slipped through. Second, even for candidates the
check correctly removed, rule #2's worklist re-promoted them in order
to maintain its invariant, undoing the InlineCallFrame check.
Fix this with two complementary changes:
1. Run the closure rule (rule #2) before the InlineCallFrame check, so
the InlineCallFrame check sees both seeded and rule-#2-promoted
candidates and is the final determination of which stay sunk.
2. Add an additional closure rule (which was already documented as a
potential rule #1): remove candidates that depend on the candidates
that were demoted (due to the InlineCallFrame mismatch). Like the
original fix, this happens rarely.
Add an ASSERT in the materialization-placement loop to verify that no
allocation reaching it would fail the InlineCallFrame check. This
catches the bug pattern in debug builds and guards against future
regressions.
Test:
JSTests/stress/object-allocation-sinking-phase-must-only-move-allocations-if-stack-trace-is-still-valid-closure-rules.js
*
JSTests/stress/object-allocation-sinking-phase-must-only-move-allocations-if-stack-trace-is-still-valid-closure-rule-promoted-parent.js:
Added.
(makeInner.return.inner):
(makeInner):
(clobber):
(sink):
(opt):
*
JSTests/stress/object-allocation-sinking-phase-must-only-move-allocations-if-stack-trace-is-still-valid-closure-rules.js:
Added.
(makeInner.return.inner):
(makeInner):
(clobber):
(sink):
(opt):
* Source/JavaScriptCore/dfg/DFGObjectAllocationSinkingPhase.cpp:
Identifier: [email protected]
Canonical link: https://commits.webkit.org/317695.179@webkitglib/2.54
Commit: 3dd1d046dd9c37914e7b5e846d2442a1fc34bc01
https://github.com/WebKit/WebKit/commit/3dd1d046dd9c37914e7b5e846d2442a1fc34bc01
Author: Kai Tamkun <[email protected]>
Date: 2026-09-02 (Wed, 02 Sep 2026)
Changed paths:
A JSTests/stress/new-regexp-untyped-soft-invalid-stale-captures.js
M Source/JavaScriptCore/dfg/DFGStrengthReductionPhase.cpp
M Source/JavaScriptCore/runtime/RegExp.cpp
M Source/JavaScriptCore/runtime/RegExp.h
M Source/JavaScriptCore/runtime/RegExpCache.cpp
Log Message:
-----------
Cherry-pick [email protected] (d74d692503fc).
https://bugs.webkit.org/show_bug.cgi?id=316723
[JSC] Validate RegExps in DFG strength reduction phase
https://bugs.webkit.org/show_bug.cgi?id=316723
rdar://178446883
Reviewed by Yusuke Suzuki.
This patch prevents conversion to NewRegExpUntyped if the regexp in
question is invalid.
Test: JSTests/stress/new-regexp-untyped-soft-invalid-stale-captures.js
* JSTests/stress/new-regexp-untyped-soft-invalid-stale-captures.js: Added.
(atDepth):
(const.make.eval):
(catch):
(try.catch):
(try.i.catch):
(exposed.i.catch):
* Source/JavaScriptCore/dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
* Source/JavaScriptCore/runtime/RegExp.cpp:
(JSC::RegExp::finishCreation):
(JSC::RegExp::updateMetadataFromPattern):
(JSC::RegExp::byteCodeCompileIfNecessary):
(JSC::RegExp::compile):
(JSC::RegExp::compileMatchOnly):
* Source/JavaScriptCore/runtime/RegExp.h:
* Source/JavaScriptCore/runtime/RegExpCache.cpp:
(JSC::RegExpCache::lookupOrCreate):
Identifier: [email protected]
Canonical link: https://commits.webkit.org/317695.180@webkitglib/2.54
Compare: https://github.com/WebKit/WebKit/compare/5f17ad47dbda...3dd1d046dd9c
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
