Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 2bd4edbe145cfb08dec3585fe4235c01869e1d7d
https://github.com/WebKit/WebKit/commit/2bd4edbe145cfb08dec3585fe4235c01869e1d7d
Author: Yusuke Suzuki <[email protected]>
Date: 2026-07-01 (Wed, 01 Jul 2026)
Changed paths:
A JSTests/stress/b3-cse-fix.js
M Source/JavaScriptCore/b3/B3EliminateCommonSubexpressions.cpp
Log Message:
-----------
[JSC] Fix B3 CSE extras adjustment
https://bugs.webkit.org/show_bug.cgi?id=318373
rdar://180277164
Reviewed by Dan Hecht.
B3 CSE can handle store with narrower width. In this case, we emit
narrowing operations to reuse the value. For example,
@a: Load32(...)
@b: Store8(@a, LocationA)
...
@d: Load8(LocationA)
is converted to
@a: Load32(...)
@b: Store8(@a, LocationA)
...
@c: BitAnd(@a, 0xff)
@d: Identity(@c)
So, we insert BitAnd to narrow @a to 8-bit size in this case.
To detect whether we need to insert these extras B3 values, we are
tracking it in m_sets.
But when we materialize it, querying to this hash table for each Value
in the graph is too costly, so we have a filter canHaveSet which checks
value's opcode to filter out the candidate. However this opcode set is
not the right one since these values can be converted to Nop / Identity
sometimes. For example, in the above CSE case, it is possible that we
detect that the above @b is meaningless and convert it to Nop because
the subsequent Store8(..., LocationA) exists (store elimination).
To filter correctly while keeping the efficacy of compile time, we add
IndexSet for matched values. Under the hood, it is BitVector and
efficienty handle the filtering.
Test: JSTests/stress/b3-cse-fix.js
* JSTests/stress/b3-cse-fix.js: Added.
* Source/JavaScriptCore/b3/B3EliminateCommonSubexpressions.cpp:
Canonical link: https://commits.webkit.org/316339@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications