Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: e1cc09104fdd8f98c6985e30a5027785dff163ff
https://github.com/WebKit/WebKit/commit/e1cc09104fdd8f98c6985e30a5027785dff163ff
Author: Keith Miller <[email protected]>
Date: 2026-05-05 (Tue, 05 May 2026)
Changed paths:
A
JSTests/wasm/stress/simd-v128-arg-clobbered-by-call-polymorphic-callee-thunk.js
M Source/JavaScriptCore/jit/RegisterSet.h
Log Message:
-----------
[JSC] normalizeWidths() should return a RegisterSet
https://bugs.webkit.org/show_bug.cgi?id=314029
rdar://176035764
Reviewed by Yusuke Suzuki.
RegisterSet::normalizeWidths() returned a ScalarRegisterSet, which only
tracks m_bits and has no m_upperBits field. Callers that assigned the
result back into a RegisterSet via the implicit conversion silently lost
all vector-width information: registers that were originally Width128
appeared as Width64 in the normalized set.
This manifested as v128 argument corruption in the wasm thunks that use
normalizeWidths() to size their register-save areas:
materializeBaselineDataGenerator, callPolymorphicCalleeGenerator, and
triggerOMGEntryTierUpThunkGenerator. Because callPolymorphicCallee
tail-calls the resolved target and materializeBaselineData returns
directly into BBQ code with v0-v7 still live as caller arg/return
registers, any v128 value in v0-v7 at the point of the thunk call would
have its high 64 bits reset to zero.
Test:
JSTests/wasm/stress/simd-v128-arg-clobbered-by-call-polymorphic-callee-thunk.js
Canonical link: https://commits.webkit.org/312610@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
