Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: aef56769428e1205845e9ba8f048c3f345818aae
https://github.com/WebKit/WebKit/commit/aef56769428e1205845e9ba8f048c3f345818aae
Author: Dan Hecht <[email protected]>
Date: 2026-08-20 (Thu, 20 Aug 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/305877.1102@webkitglib/2.52
Commit: 1dc38193dcd90b66692981344a9de924f36685ba
https://github.com/WebKit/WebKit/commit/1dc38193dcd90b66692981344a9de924f36685ba
Author: Dan Hecht <[email protected]>
Date: 2026-08-20 (Thu, 20 Aug 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/305877.1103@webkitglib/2.52
Commit: 2091c251b2ea0b9fb85ea476a2ec21f8a7a7cc53
https://github.com/WebKit/WebKit/commit/2091c251b2ea0b9fb85ea476a2ec21f8a7a7cc53
Author: Kai Tamkun <[email protected]>
Date: 2026-08-20 (Thu, 20 Aug 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/305877.1104@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/4fb33923db2f...2091c251b2ea
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
