Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 9c096feb7d8963e513f0af3320e2d9b7ac4ea393 https://github.com/WebKit/WebKit/commit/9c096feb7d8963e513f0af3320e2d9b7ac4ea393 Author: Keith Miller <keith_mil...@apple.com> Date: 2024-05-24 (Fri, 24 May 2024)
Changed paths: M JSTests/stress/generator-cell-with-type.js A JSTests/stress/stack-overflow-in-scope-with-catch.js M Source/JavaScriptCore/Scripts/process-entitlements.sh M Source/JavaScriptCore/dfg/DFGArrayifySlowPathGenerator.h M Source/JavaScriptCore/dfg/DFGCallArrayAllocatorSlowPathGenerator.h M Source/JavaScriptCore/dfg/DFGCallCreateDirectArgumentsSlowPathGenerator.h M Source/JavaScriptCore/dfg/DFGRegisterBank.h M Source/JavaScriptCore/dfg/DFGSaneStringGetByValSlowPathGenerator.h M Source/JavaScriptCore/dfg/DFGSilentRegisterSavePlan.h M Source/JavaScriptCore/dfg/DFGSlowPathGenerator.h M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.h M Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp M Source/JavaScriptCore/jit/AssemblyHelpers.cpp M Source/JavaScriptCore/jit/GPRInfo.h M Source/JavaScriptCore/jit/OperationResult.h M Source/JavaScriptCore/jit/Reg.h M Source/JavaScriptCore/jit/RegisterSet.h Log Message: ----------- exceptions can't always be checked under silent spill in DFG https://bugs.webkit.org/show_bug.cgi?id=274291 rdar://128067350 Reviewed by Yusuke Suzuki. I originally left a `probeDebug` in the change, which caused perf regressions. This is just removing that debugging logic and relanding. If we're catching an exception in the same DFG frame it's potentially not safe to check for exceptions under a silent spill. This is because the OSR exit ramp does not know about the silent spill. So values will not be restored. There were a couple of possible fixes: 1) teach the DFGVariableEventStream about exceptions under silent spill. 2) add extra metadata about the fact we’re under a silent spill and silent fill before hitting the OSR exit ramp. 3) move the exception to an unused gpr until we can silent fill if needed. I went with option 3. 1. has the problem that it's complicated and might be a memory regression. 2. could bloat code size. I also noticed that my `requires (!OperationHasResult<T>)` checks were not properly eliminating overloads. This is because when you do e.g. `requires (!OperationHasResult<int>)` the `OperationHasResult<int>` will fail SFINAE but that just makes the concept false which then becomes true in the requirement. Instead we now have a new `OperationIsVoid<T>` concept. Canonical link: https://commits.webkit.org/279295@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications _______________________________________________ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes