Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: ab55d8679525a3a67493f6f637ccd4e4a714afdf
https://github.com/WebKit/WebKit/commit/ab55d8679525a3a67493f6f637ccd4e4a714afdf
Author: Keith Miller <[email protected]>
Date: 2025-12-19 (Fri, 19 Dec 2025)
Changed paths:
M JSTests/stress/fused-jeq.js
M Source/JavaScriptCore/CMakeLists.txt
M Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj
M Source/JavaScriptCore/Sources.txt
M Source/JavaScriptCore/bytecode/Operands.h
M Source/JavaScriptCore/generator/GeneratedFile.rb
M Source/JavaScriptCore/jit/AssemblyHelpers.h
M Source/JavaScriptCore/jit/BaselineJITPlan.cpp
M Source/JavaScriptCore/jit/JIT.cpp
M Source/JavaScriptCore/jit/JIT.h
M Source/JavaScriptCore/jit/JITCall.cpp
M Source/JavaScriptCore/jit/JITDisassembler.cpp
M Source/JavaScriptCore/jit/JITDisassembler.h
M Source/JavaScriptCore/jit/JITInlines.h
M Source/JavaScriptCore/jit/RegisterSet.h
M Source/JavaScriptCore/jit/SimpleRegisterAllocator.h
A Source/JavaScriptCore/lol/LOLJIT.cpp
A Source/JavaScriptCore/lol/LOLJIT.h
A Source/JavaScriptCore/lol/LOLRegisterAllocator.h
M Source/JavaScriptCore/runtime/Options.cpp
M Source/JavaScriptCore/runtime/OptionsList.h
M Source/JavaScriptCore/wasm/WasmBBQJIT.cpp
Log Message:
-----------
Add the first part of the new Light Optimization Layer JIT
https://bugs.webkit.org/show_bug.cgi?id=304250
rdar://166615545
Reviewed by Marcus Plutowski and Yusuke Suzuki.
This patch adds the outline of the new LOL JIT. LOL differs from the
existing baseline in that we intend to do limited inter-bytecode
optimizations. Namely, we're going to try to register allocate between
bytecodes.
To make slow paths efficient (and eventually OSR exiting possible without
a huge memory regression) the plan is to make the register allocator
replayable. This works by having the register alligator be templated, so
that different backends can either generate code for the allocation or
simply replay what was allocated the first time. To make testing of the
bytecodes that I wrote possible whenever LOL JIT sees a bytecode that it
doesn't know it will just flush all registers. This obviously generates
poor code quality but as the number of bytecodes supported increases
it should matter less and less.
Each bytecode has an overload in LOL::RegisterAllocator which knows about
the number of uses, defs and scratches a given bytecode needs. The other
upside is that when tuning in the future we can precisely control the
logic in one place. e.g. if we know that an IC uses x0-x4 we can always
flush those registers and shuffle the result to x0 and any future
replayers (i.e. slow paths/OSR) would see that change in the register
state.
I also added logging so we can see the register allocation state in
disassembly, which has been very helpful in debugging.
Some of the interesting cases I had to fix for this PR are:
1) The start of the next instruction and the slow-to-hot return point
are now different. This is because the next instruction could be a jump
target (or not supported) so we have to flush everything to the stack.
2) The current Baseline JIT only calls into BytecodeIndices that actually
have a slow path. This differs from LOL JIT where we switch over every
instruction to replay the register allocator.
Canonical link: https://commits.webkit.org/304769@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
