Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2026-04-19 02:10:26 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibJS/Bytecode/ASTCodegen.cpp

4384 lines
207 KiB
C++
Raw Normal View History

LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
/*
LibJS: Constant-fold unary expressions !0 and !1 are very common patterns in minified JavaScript, and we should figure out that they're constants. :^)
2025-03-25 18:01:35 +00:00
* Copyright (c) 2021-2025, Andreas Kling <andreas@ladybird.org>
LibJS: Add bytecode generation for BinaryOp::In
2021-06-07 21:13:37 +01:00
* Copyright (c) 2021, Linus Groh <linusg@serenityos.org>
LibJS: Generate bytecode for throw statements
2021-06-09 18:18:56 +02:00
* Copyright (c) 2021, Gunnar Beutner <gbeutner@serenityos.org>
LibJS: Implement bytecode generation for switch
2021-06-11 00:36:16 +02:00
* Copyright (c) 2021, Marcin Gasperowicz <xnooga@gmail.com>
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
LibJS: Add support for SpreadExpressions in array literals for bytecode For this it adds another opcode `Append $lhs` which appends the accumulator to the Array in $lhs, optionally spreading it.
2022-09-09 15:23:02 +02:00
#include <AK/Find.h>
LibJS/Bytecode: Bunch all tests together in switch statement codegen Before this change, switch codegen would interleave bytecode like this: (test for case 1) (code for case 1) (test for case 2) (code for case 2) This meant that we often had to make many large jumps while looking for the matching case, since code for each case can be huge. It now looks like this instead: (test for case 1) (test for case 2) (code for case 1) (code for case 2) This way, we can just fall through the tests until we hit one that fits, without having to make any large jumps.
2024-05-08 13:08:38 +02:00
#include <AK/Queue.h>
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
#include <LibJS/AST.h>
#include <LibJS/Bytecode/Generator.h>
#include <LibJS/Bytecode/Instruction.h>
#include <LibJS/Bytecode/Op.h>
#include <LibJS/Bytecode/Register.h>
LibJS: Generate bytecode for entering nested lexical environments This adds a new PushLexicalEnvironment instruction that creates a new LexicalEnvironment and pushes it on the VM's scope stack. There is no corresponding PopLexicalEnvironment instruction yet, so this will behave incorrectly with let/const scopes for example.
2021-06-10 22:12:21 +02:00
#include <LibJS/Bytecode/StringTable.h>
LibJS: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
#include <LibJS/Runtime/Environment.h>
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
#include <LibJS/Runtime/ErrorTypes.h>
LibJS: Populate ClassBlueprint during codegen Build a ClassBlueprint from ClassExpression elements at codegen time: - Methods/getters/setters: register SharedFunctionInstanceData from the method's FunctionExpression - Field initializers with literal values (numbers, booleans, null, strings, negated numbers): store the value directly, avoiding function creation entirely - Field initializers with non-literal values: wrap in ClassFieldInitializerStatement and create SharedFunctionInstanceData - Static initializers: create SharedFunctionInstanceData from the function body - Constructor: register SharedFunctionInstanceData from the constructor's FunctionExpression Add public accessors to ClassMethod::function() and StaticInitializer::function_body() for codegen access. The blueprint is registered but not yet used by NewClass (dual path). No behavioral change.
2026-02-11 00:20:47 +01:00
#include <LibJS/Runtime/PrimitiveString.h>
#include <LibJS/Runtime/SharedFunctionInstanceData.h>
LibJS: Reduce number of template literal op codes There is no need to concat empty string literals when building template literals. Now strings will only be concatenated if they need to be. To handle the edge case where the first segment is not a string literal, a new `ToString` op code has been added to ensure the value is a string concatenating more strings. In addition, basic const folding is now supported for template literal constants (templates with no interpolated values), which is commonly used for multi-line string constants.
2026-01-22 17:23:19 -08:00
#include <LibJS/Runtime/VM.h>
LibJS: Constant-fold unary expressions !0 and !1 are very common patterns in minified JavaScript, and we should figure out that they're constants. :^)
2025-03-25 18:01:35 +00:00
#include <LibJS/Runtime/ValueInlines.h>
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
namespace JS {
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
using namespace JS::Bytecode;
LibJS: Handle BigInt literal keys in class field initializer naming When a class field has a BigInt literal key like `128n = class {}`, the anonymous class should get the name "128". The codegen path handles Identifier, StringLiteral, and NumericLiteral keys but was missing BigInt keys, causing the name to be empty. Parse the BigInt literal value at codegen time and convert it to a decimal string for both the field_name (anonymous function naming) and class_field_initializer_name (eval("arguments") checking) paths.
2026-02-11 19:45:44 +01:00
static String bigint_literal_to_decimal_string(BigIntLiteral const& literal)
{
auto const& raw = literal.raw_value();
auto integer = [&] {
if (raw[0] == '0' && raw.length() >= 3) {
if (raw[1] == 'x' || raw[1] == 'X')
return MUST(Crypto::SignedBigInteger::from_base(16, raw.substring(2, raw.length() - 3)));
if (raw[1] == 'o' || raw[1] == 'O')
return MUST(Crypto::SignedBigInteger::from_base(8, raw.substring(2, raw.length() - 3)));
if (raw[1] == 'b' || raw[1] == 'B')
return MUST(Crypto::SignedBigInteger::from_base(2, raw.substring(2, raw.length() - 3)));
}
return MUST(Crypto::SignedBigInteger::from_base(10, raw.substring(0, raw.length() - 1)));
}();
return MUST(integer.to_base(10));
}
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
static ScopedOperand choose_dst(Bytecode::Generator& generator, Optional<ScopedOperand> const& preferred_dst)
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
{
if (preferred_dst.has_value())
return preferred_dst.value();
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
return generator.allocate_register();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> ASTNode::generate_bytecode(Bytecode::Generator& generator, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
{
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
generator.emit_todo(class_name());
return {};
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> ScopeNode::generate_bytecode(Bytecode::Generator& generator, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS/Bytecode: Leave BlockDeclarationInstantiation in C++ Instead of implementing this AO in bytecode, we now have an instruction for it that simply invokes the C++ implementation. This allows us to simplify Bytecode::Generator quite a bit by removing all the variable scope tracking.
2023-06-16 16:34:47 +02:00
bool did_create_lexical_environment = false;
LibJS/Bytecode: Actually exit `switch` statement's lexical scope 95 new passes on test262. :^)
2023-06-25 07:37:24 +02:00
if (is<BlockStatement>(*this)) {
LibJS: More properly implement scoping rules in bytecode codegen Now we emit CreateVariable and SetVariable with the appropriate initialization/environment modes, much closer to the spec. This makes a whole lot of things like let/const variables, function and variable hoisting and some other things work :^)
2022-02-12 19:48:45 +03:30
if (has_lexical_declarations()) {
LibJS/Bytecode: Don't create empty lexical environments This patch stops emitting the BlockDeclarationInstantiation instruction when there are no locals, and no function declarations in the scope. We were spending 20% of CPU time on https://ventrella.com/Clusters/ just creating empty environments for no reason.
2024-05-11 13:25:08 +02:00
did_create_lexical_environment = generator.emit_block_declaration_instantiation(*this);
LibJS: More properly implement scoping rules in bytecode codegen Now we emit CreateVariable and SetVariable with the appropriate initialization/environment modes, much closer to the spec. This makes a whole lot of things like let/const variables, function and variable hoisting and some other things work :^)
2022-02-12 19:48:45 +03:30
}
} else if (is<Program>(*this)) {
LibJS/Bytecode: Leave GlobalDeclarationInstantiation in C++ Don't try to implement this AO in bytecode. Instead, the bytecode Interpreter class now has a run() API with the same inputs as the AST interpreter. It sets up the necessary environments etc, including invoking the GlobalDeclarationInstantiation AO.
2023-06-15 12:36:57 +02:00
// GlobalDeclarationInstantiation is handled by the C++ AO.
LibJS: More properly implement scoping rules in bytecode codegen Now we emit CreateVariable and SetVariable with the appropriate initialization/environment modes, much closer to the spec. This makes a whole lot of things like let/const variables, function and variable hoisting and some other things work :^)
2022-02-12 19:48:45 +03:30
} else {
LibJS/Bytecode: Leave FunctionDeclarationInstantantiation in C++ Instead of trying to implement this AO in bytecode, we can just let it be a C++ thing. Once we implement fast uncaptured locals, we won't even be calling it super often.
2023-06-15 09:14:25 +02:00
// FunctionDeclarationInstantiation is handled by the C++ AO.
LibJS: More properly implement scoping rules in bytecode codegen Now we emit CreateVariable and SetVariable with the appropriate initialization/environment modes, much closer to the spec. This makes a whole lot of things like let/const variables, function and variable hoisting and some other things work :^)
2022-02-12 19:48:45 +03:30
}
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
Optional<ScopedOperand> last_result;
LibJS: Don't generate code after we've encountered a terminating op
2021-06-09 19:57:18 +02:00
for (auto& child : children()) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto result = child->generate_bytecode(generator);
LibJS: Don't track "last result" of ScopeNode if we don't need it This prevents unnecessary bytecode register allocation.
2025-04-07 15:59:30 +02:00
if (generator.must_propagate_completion()) {
LibJS: Fix UpdateEmpty completion value semantics for loops/switch/if When a loop or switch body produces an abrupt completion (break or continue) with an empty value, the ES spec requires UpdateEmpty to replace the empty value with the last non-empty completion value V. The bytecode compiler was failing to do this because it only updated the completion register after body codegen, guarded by !is_current_block_terminated(). When break/continue terminated the block, the update was skipped. Fix this with three changes: 1. Introduce a CompletionRegisterScope that tells ScopeNode::generate_bytecode to eagerly emit Mov instructions into the completion register after each value-producing statement. This ensures the register is up to date before any break or continue fires. 2. Give IfStatement its own CompletionRegisterScope (initialized to undefined) during branch evaluation. This models the spec's UpdateEmpty(stmtCompletion, undefined) for if-statements: when break/continue fires inside an if-branch, the scoped jump propagation sees that the if's completion register differs from the loop's and emits a Mov, correctly replacing the eagerly written value with undefined. Without this, code like { 3; if (true) { break; } else { } } would incorrectly carry the value 3 instead of undefined through the break. 3. Capture loop body results and emit a fallback Mov for non-ScopeNode bodies (e.g. bare expression statements like do x=1; while(false)) that don't participate in the eager CompletionRegisterScope update mechanism. For labelled break/continue that cross loop boundaries, the jump codegen now propagates the inner completion register to the target scope's completion register before emitting the jump. Also fix ForStatement to use a proper completion register (previously it returned the body result directly, which was wrong for empty bodies and break-with-no-value cases).
2026-02-10 23:25:24 +01:00
if (result.has_value()) {
LibJS: Don't track "last result" of ScopeNode if we don't need it This prevents unnecessary bytecode register allocation.
2025-04-07 15:59:30 +02:00
last_result = result;
LibJS: Fix UpdateEmpty completion value semantics for loops/switch/if When a loop or switch body produces an abrupt completion (break or continue) with an empty value, the ES spec requires UpdateEmpty to replace the empty value with the last non-empty completion value V. The bytecode compiler was failing to do this because it only updated the completion register after body codegen, guarded by !is_current_block_terminated(). When break/continue terminated the block, the update was skipped. Fix this with three changes: 1. Introduce a CompletionRegisterScope that tells ScopeNode::generate_bytecode to eagerly emit Mov instructions into the completion register after each value-producing statement. This ensures the register is up to date before any break or continue fires. 2. Give IfStatement its own CompletionRegisterScope (initialized to undefined) during branch evaluation. This models the spec's UpdateEmpty(stmtCompletion, undefined) for if-statements: when break/continue fires inside an if-branch, the scoped jump propagation sees that the if's completion register differs from the loop's and emits a Mov, correctly replacing the eagerly written value with undefined. Without this, code like { 3; if (true) { break; } else { } } would incorrectly carry the value 3 instead of undefined through the break. 3. Capture loop body results and emit a fallback Mov for non-ScopeNode bodies (e.g. bare expression statements like do x=1; while(false)) that don't participate in the eager CompletionRegisterScope update mechanism. For labelled break/continue that cross loop boundaries, the jump codegen now propagates the inner completion register to the target scope's completion register before emitting the jump. Also fix ForStatement to use a proper completion register (previously it returned the body result directly, which was wrong for empty bodies and break-with-no-value cases).
2026-02-10 23:25:24 +01:00
if (!generator.is_current_block_terminated()) {
if (auto completion_reg = generator.current_completion_register(); completion_reg.has_value())
generator.emit_mov(*completion_reg, *result);
}
}
LibJS: Don't track "last result" of ScopeNode if we don't need it This prevents unnecessary bytecode register allocation.
2025-04-07 15:59:30 +02:00
}
LibJS: Don't generate code after we've encountered a terminating op
2021-06-09 19:57:18 +02:00
if (generator.is_current_block_terminated())
break;
}
LibJS: Make ASTNode::generate_bytecode() fallible Instead of crashing on the spot, return a descriptive error that will eventually continue its days as a javascript "InternalError" exception. This should make random crashes with BC less likely.
2022-02-12 19:54:08 +03:30
LibJS/Bytecode: Leave BlockDeclarationInstantiation in C++ Instead of implementing this AO in bytecode, we now have an instruction for it that simply invokes the C++ implementation. This allows us to simplify Bytecode::Generator quite a bit by removing all the variable scope tracking.
2023-06-16 16:34:47 +02:00
if (did_create_lexical_environment)
LibJS: More properly implement scoping rules in bytecode codegen Now we emit CreateVariable and SetVariable with the appropriate initialization/environment modes, much closer to the spec. This makes a whole lot of things like let/const variables, function and variable hoisting and some other things work :^)
2022-02-12 19:48:45 +03:30
generator.end_variable_scope();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return last_result;
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> EmptyStatement::generate_bytecode(Bytecode::Generator&, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS: Add bytecode generation for EmptyStatement
2021-06-07 20:47:26 +02:00
{
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
return Optional<ScopedOperand> {};
LibJS: Add bytecode generation for EmptyStatement
2021-06-07 20:47:26 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> ExpressionStatement::generate_bytecode(Bytecode::Generator& generator, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS: Make ASTNode::generate_bytecode() fallible Instead of crashing on the spot, return a descriptive error that will eventually continue its days as a javascript "InternalError" exception. This should make random crashes with BC less likely.
2022-02-12 19:54:08 +03:30
return m_expression->generate_bytecode(generator);
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
}
LibJS: Constant-fold unary expressions !0 and !1 are very common patterns in minified JavaScript, and we should figure out that they're constants. :^)
2025-03-25 18:01:35 +00:00
static ThrowCompletionOr<ScopedOperand> constant_fold_unary_expression(Generator& generator, Value value, UnaryOp op)
{
switch (op) {
case UnaryOp::Minus:
return generator.add_constant(Value(-TRY(value.to_double(generator.vm()))));
case UnaryOp::Plus:
return generator.add_constant(Value(+TRY(value.to_double(generator.vm()))));
case UnaryOp::BitwiseNot:
return generator.add_constant(TRY(bitwise_not(generator.vm(), value)));
case UnaryOp::Not:
return generator.add_constant(Value(!value.to_boolean()));
default:
return throw_completion(js_null());
}
}
LibJS: Optimize double boolean not (`!!`) operation This is a common way to convert a value to a boolean. Instead of doing a boolean conversion and 2 negate operations, we replace this with a single `ToBoolean` op code.
2026-01-06 16:03:23 -08:00
static Optional<ScopedOperand> try_constant_fold_unary_expression(Generator& generator, ScopedOperand& operand, UnaryOp op)
{
if (operand.operand().is_constant()) {
// OPTIMIZATION: Do some basic constant folding for unary operations on numbers.
auto value = generator.get_constant(operand);
if (auto result = constant_fold_unary_expression(generator, value, op); !result.is_error())
return result.release_value();
}
return {};
}
LibJS/Bytecode: Perform constant folding on binary expressions This turns expressions like `(2 + 3) * 8 / 2` into a constant (20) at bytecode compilation time instead of generating instructions to calculate the value.
2024-05-31 21:49:46 +02:00
static ThrowCompletionOr<ScopedOperand> constant_fold_binary_expression(Generator& generator, Value lhs, Value rhs, BinaryOp m_op)
{
switch (m_op) {
case BinaryOp::Addition:
return generator.add_constant(TRY(add(generator.vm(), lhs, rhs)));
case BinaryOp::Subtraction:
return generator.add_constant(TRY(sub(generator.vm(), lhs, rhs)));
case BinaryOp::Multiplication:
return generator.add_constant(TRY(mul(generator.vm(), lhs, rhs)));
case BinaryOp::Division:
return generator.add_constant(TRY(div(generator.vm(), lhs, rhs)));
case BinaryOp::Modulo:
return generator.add_constant(TRY(mod(generator.vm(), lhs, rhs)));
case BinaryOp::Exponentiation:
return generator.add_constant(TRY(exp(generator.vm(), lhs, rhs)));
case BinaryOp::GreaterThan:
LibJS: Avoid roundtrip through Value for comparison bytecode evaluation 1.1x speedup on strictly-equals-object.js
2025-05-08 15:19:35 +12:00
return generator.add_constant(Value { TRY(greater_than(generator.vm(), lhs, rhs)) });
LibJS/Bytecode: Perform constant folding on binary expressions This turns expressions like `(2 + 3) * 8 / 2` into a constant (20) at bytecode compilation time instead of generating instructions to calculate the value.
2024-05-31 21:49:46 +02:00
case BinaryOp::GreaterThanEquals:
LibJS: Avoid roundtrip through Value for comparison bytecode evaluation 1.1x speedup on strictly-equals-object.js
2025-05-08 15:19:35 +12:00
return generator.add_constant(Value { TRY(greater_than_equals(generator.vm(), lhs, rhs)) });
LibJS/Bytecode: Perform constant folding on binary expressions This turns expressions like `(2 + 3) * 8 / 2` into a constant (20) at bytecode compilation time instead of generating instructions to calculate the value.
2024-05-31 21:49:46 +02:00
case BinaryOp::LessThan:
LibJS: Avoid roundtrip through Value for comparison bytecode evaluation 1.1x speedup on strictly-equals-object.js
2025-05-08 15:19:35 +12:00
return generator.add_constant(Value { TRY(less_than(generator.vm(), lhs, rhs)) });
LibJS/Bytecode: Perform constant folding on binary expressions This turns expressions like `(2 + 3) * 8 / 2` into a constant (20) at bytecode compilation time instead of generating instructions to calculate the value.
2024-05-31 21:49:46 +02:00
case BinaryOp::LessThanEquals:
LibJS: Avoid roundtrip through Value for comparison bytecode evaluation 1.1x speedup on strictly-equals-object.js
2025-05-08 15:19:35 +12:00
return generator.add_constant(Value { TRY(less_than_equals(generator.vm(), lhs, rhs)) });
LibJS/Bytecode: Perform constant folding on binary expressions This turns expressions like `(2 + 3) * 8 / 2` into a constant (20) at bytecode compilation time instead of generating instructions to calculate the value.
2024-05-31 21:49:46 +02:00
case BinaryOp::LooselyInequals:
return generator.add_constant(Value(!TRY(is_loosely_equal(generator.vm(), lhs, rhs))));
case BinaryOp::LooselyEquals:
return generator.add_constant(Value(TRY(is_loosely_equal(generator.vm(), lhs, rhs))));
case BinaryOp::StrictlyInequals:
return generator.add_constant(Value(!is_strictly_equal(lhs, rhs)));
case BinaryOp::StrictlyEquals:
return generator.add_constant(Value(is_strictly_equal(lhs, rhs)));
case BinaryOp::BitwiseAnd:
return generator.add_constant(TRY(bitwise_and(generator.vm(), lhs, rhs)));
case BinaryOp::BitwiseOr:
return generator.add_constant(TRY(bitwise_or(generator.vm(), lhs, rhs)));
case BinaryOp::BitwiseXor:
return generator.add_constant(TRY(bitwise_xor(generator.vm(), lhs, rhs)));
case BinaryOp::LeftShift:
return generator.add_constant(TRY(left_shift(generator.vm(), lhs, rhs)));
case BinaryOp::RightShift:
return generator.add_constant(TRY(right_shift(generator.vm(), lhs, rhs)));
case BinaryOp::UnsignedRightShift:
return generator.add_constant(TRY(unsigned_right_shift(generator.vm(), lhs, rhs)));
case BinaryOp::In:
case BinaryOp::InstanceOf:
// NOTE: We just have to throw *something* to indicate that this is not a constant foldable operation.
return throw_completion(js_null());
default:
VERIFY_NOT_REACHED();
}
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> BinaryExpression::generate_bytecode(Bytecode::Generator& generator, Optional<ScopedOperand> preferred_dst) const
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS/Bytecode: Support `in` binary operator for private fields 11 new passes on test262. :^)
2023-07-05 12:42:50 +02:00
if (m_op == BinaryOp::In && is<PrivateIdentifier>(*m_lhs)) {
auto const& private_identifier = static_cast<PrivateIdentifier const&>(*m_lhs).string();
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto base = m_rhs->generate_bytecode(generator).value();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
auto dst = choose_dst(generator, preferred_dst);
generator.emit<Bytecode::Op::HasPrivateId>(dst, base, generator.intern_identifier(private_identifier));
return dst;
LibJS/Bytecode: Support `in` binary operator for private fields 11 new passes on test262. :^)
2023-07-05 12:42:50 +02:00
}
LibJS/Bytecode: Round constant operands of bitwise binary expressions This helps some of the Cloudflare Turnstile stuff run faster, since they are deliberately screwing with JS engines by asking us to do a bunch of bitwise operations on e.g 65535.56 By rounding such values in bytecode generation, the interpreter can stay on the happy path while executing, and finish quite a bit faster.
2024-05-09 15:17:34 +02:00
// OPTIMIZATION: If LHS and/or RHS are numeric literals, we make sure they are converted to i32/u32
// as appropriate, to avoid having to perform these conversions at runtime.
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto get_left_side = [&](Expression const& side) -> Optional<ScopedOperand> {
LibJS/Bytecode: Round constant operands of bitwise binary expressions This helps some of the Cloudflare Turnstile stuff run faster, since they are deliberately screwing with JS engines by asking us to do a bunch of bitwise operations on e.g 65535.56 By rounding such values in bytecode generation, the interpreter can stay on the happy path while executing, and finish quite a bit faster.
2024-05-09 15:17:34 +02:00
switch (m_op) {
case BinaryOp::BitwiseAnd:
case BinaryOp::BitwiseOr:
case BinaryOp::BitwiseXor:
case BinaryOp::LeftShift:
case BinaryOp::RightShift:
case BinaryOp::UnsignedRightShift:
// LHS will always be converted to i32 for these ops.
if (side.is_numeric_literal()) {
auto value = MUST(static_cast<NumericLiteral const&>(side).value().to_i32(generator.vm()));
return generator.add_constant(Value(value));
}
break;
default:
break;
}
return side.generate_bytecode(generator);
};
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto get_right_side = [&](Expression const& side) -> Optional<ScopedOperand> {
LibJS/Bytecode: Round constant operands of bitwise binary expressions This helps some of the Cloudflare Turnstile stuff run faster, since they are deliberately screwing with JS engines by asking us to do a bunch of bitwise operations on e.g 65535.56 By rounding such values in bytecode generation, the interpreter can stay on the happy path while executing, and finish quite a bit faster.
2024-05-09 15:17:34 +02:00
switch (m_op) {
case BinaryOp::BitwiseAnd:
case BinaryOp::BitwiseOr:
case BinaryOp::BitwiseXor:
// RHS will always be converted to i32 for these ops.
if (side.is_numeric_literal()) {
auto value = MUST(static_cast<NumericLiteral const&>(side).value().to_i32(generator.vm()));
return generator.add_constant(Value(value));
}
break;
case BinaryOp::LeftShift:
case BinaryOp::RightShift:
case BinaryOp::UnsignedRightShift:
// RHS will always be converted to u32 for these ops.
if (side.is_numeric_literal()) {
auto value = MUST(static_cast<NumericLiteral const&>(side).value().to_u32(generator.vm()));
return generator.add_constant(Value(value));
}
break;
default:
break;
}
return side.generate_bytecode(generator);
};
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto lhs = get_left_side(*m_lhs).value();
auto rhs = get_right_side(*m_rhs).value();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
auto dst = choose_dst(generator, preferred_dst);
LibJS/Bytecode: Perform constant folding on binary expressions This turns expressions like `(2 + 3) * 8 / 2` into a constant (20) at bytecode compilation time instead of generating instructions to calculate the value.
2024-05-31 21:49:46 +02:00
// OPTIMIZATION: Do some basic constant folding for binary operations.
if (lhs.operand().is_constant() && rhs.operand().is_constant()) {
if (auto result = constant_fold_binary_expression(generator, generator.get_constant(lhs), generator.get_constant(rhs), m_op); !result.is_error())
return result.release_value();
}
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
switch (m_op) {
case BinaryOp::Addition:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::Add>(dst, lhs, rhs);
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
break;
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
case BinaryOp::Subtraction:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::Sub>(dst, lhs, rhs);
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
break;
LibJS: Add bytecode instructions for multiplication and division
2021-06-07 19:17:20 +02:00
case BinaryOp::Multiplication:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::Mul>(dst, lhs, rhs);
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
break;
LibJS: Add bytecode instructions for multiplication and division
2021-06-07 19:17:20 +02:00
case BinaryOp::Division:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::Div>(dst, lhs, rhs);
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
break;
LibJS: Add bytecode instructions for modulo and exponentiation
2021-06-07 19:37:23 +02:00
case BinaryOp::Modulo:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::Mod>(dst, lhs, rhs);
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
break;
LibJS: Add bytecode instructions for modulo and exponentiation
2021-06-07 19:37:23 +02:00
case BinaryOp::Exponentiation:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::Exp>(dst, lhs, rhs);
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
break;
LibJS: Add bytecode ops for >, >= and <=
2021-06-07 19:57:38 +02:00
case BinaryOp::GreaterThan:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::GreaterThan>(dst, lhs, rhs);
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
break;
LibJS: Add bytecode ops for >, >= and <=
2021-06-07 19:57:38 +02:00
case BinaryOp::GreaterThanEquals:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::GreaterThanEquals>(dst, lhs, rhs);
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
break;
LibJS: Add LessThan bytecode instruction :^)
2021-06-04 12:03:57 +02:00
case BinaryOp::LessThan:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::LessThan>(dst, lhs, rhs);
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
break;
LibJS: Add bytecode ops for >, >= and <=
2021-06-07 19:57:38 +02:00
case BinaryOp::LessThanEquals:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::LessThanEquals>(dst, lhs, rhs);
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
break;
LibJS: Rename {Abstract,Typed => Loosely,Strictly}{Equals,Inequals} This affects the AST's BinaryOp enum as well as the Bytecode's ENUMERATE_BYTECODE_OPS and JS_ENUMERATE_COMMON_BINARY_OPS macros.
2021-09-24 00:06:10 +02:00
case BinaryOp::LooselyInequals:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::LooselyInequals>(dst, lhs, rhs);
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
break;
LibJS: Rename {Abstract,Typed => Loosely,Strictly}{Equals,Inequals} This affects the AST's BinaryOp enum as well as the Bytecode's ENUMERATE_BYTECODE_OPS and JS_ENUMERATE_COMMON_BINARY_OPS macros.
2021-09-24 00:06:10 +02:00
case BinaryOp::LooselyEquals:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::LooselyEquals>(dst, lhs, rhs);
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
break;
LibJS: Rename {Abstract,Typed => Loosely,Strictly}{Equals,Inequals} This affects the AST's BinaryOp enum as well as the Bytecode's ENUMERATE_BYTECODE_OPS and JS_ENUMERATE_COMMON_BINARY_OPS macros.
2021-09-24 00:06:10 +02:00
case BinaryOp::StrictlyInequals:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::StrictlyInequals>(dst, lhs, rhs);
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
break;
LibJS: Rename {Abstract,Typed => Loosely,Strictly}{Equals,Inequals} This affects the AST's BinaryOp enum as well as the Bytecode's ENUMERATE_BYTECODE_OPS and JS_ENUMERATE_COMMON_BINARY_OPS macros.
2021-09-24 00:06:10 +02:00
case BinaryOp::StrictlyEquals:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::StrictlyEquals>(dst, lhs, rhs);
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
break;
LibJS: Add bytecode ops for &, | and ^
2021-06-07 19:16:04 +01:00
case BinaryOp::BitwiseAnd:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::BitwiseAnd>(dst, lhs, rhs);
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
break;
LibJS: Add bytecode ops for &, | and ^
2021-06-07 19:16:04 +01:00
case BinaryOp::BitwiseOr:
LibJS: Add dedicated bytecode instruction for x|0 (ToInt32) This operation is a very common technique to force a value to become a 32-bit integer.
2025-12-15 00:14:15 -06:00
if (rhs.operand().is_constant() && generator.get_constant(rhs).is_int32() && generator.get_constant(rhs).as_i32() == 0) {
// OPTIMIZATION: x | 0 == ToInt32(x)
generator.emit<Bytecode::Op::ToInt32>(dst, lhs);
break;
}
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::BitwiseOr>(dst, lhs, rhs);
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
break;
LibJS: Add bytecode ops for &, | and ^
2021-06-07 19:16:04 +01:00
case BinaryOp::BitwiseXor:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::BitwiseXor>(dst, lhs, rhs);
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
break;
LibJS: Add bytecode ops for <<, >> and >>>
2021-06-07 20:14:12 +01:00
case BinaryOp::LeftShift:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::LeftShift>(dst, lhs, rhs);
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
break;
LibJS: Add bytecode ops for <<, >> and >>>
2021-06-07 20:14:12 +01:00
case BinaryOp::RightShift:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::RightShift>(dst, lhs, rhs);
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
break;
LibJS: Add bytecode ops for <<, >> and >>>
2021-06-07 20:14:12 +01:00
case BinaryOp::UnsignedRightShift:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::UnsignedRightShift>(dst, lhs, rhs);
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
break;
LibJS: Add bytecode generation for BinaryOp::In
2021-06-07 21:13:37 +01:00
case BinaryOp::In:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::In>(dst, lhs, rhs);
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
break;
LibJS: Add bytecode generation for BinaryOp::InstanceOf
2021-06-07 21:18:19 +01:00
case BinaryOp::InstanceOf:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::InstanceOf>(dst, lhs, rhs);
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
break;
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
default:
LibJS: Add bytecode generation for BinaryOp::InstanceOf
2021-06-07 21:18:19 +01:00
VERIFY_NOT_REACHED();
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
}
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return dst;
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
static Optional<ScopedOperand> constant_fold_logical_expression(Bytecode::Generator& generator, Optional<ScopedOperand> preferred_dst, ScopedOperand& lhs, LogicalExpression const* expr)
LibJS: Constant fold `LogicalExpression` Logical expressions like `true || false` are now constant folded. This also allows for dead code elimination if we know the right-hand side of the expression will never be evaluated (such as `false && f()` or `true || f()`). In the test suites, the values are now being constant folded at compile time. To ensure that the actual evaluation logic is being called properly, I had to duplicate the tests and call them via a function so the compiler would not optimize the evaluation logic away. This also demotes `NaN` and `Infinity` identifiers to `nan` and `inf` double literals, which will further help with const folding.
2026-01-11 12:36:23 -08:00
{
auto constant = generator.get_constant(lhs);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto return_rhs = [&] -> Optional<ScopedOperand> {
LibJS: Constant fold `LogicalExpression` Logical expressions like `true || false` are now constant folded. This also allows for dead code elimination if we know the right-hand side of the expression will never be evaluated (such as `false && f()` or `true || f()`). In the test suites, the values are now being constant folded at compile time. To ensure that the actual evaluation logic is being called properly, I had to duplicate the tests and call them via a function so the compiler would not optimize the evaluation logic away. This also demotes `NaN` and `Infinity` identifiers to `nan` and `inf` double literals, which will further help with const folding.
2026-01-11 12:36:23 -08:00
auto dst = choose_dst(generator, preferred_dst);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto rhs = expr->rhs()->generate_bytecode(generator, dst).value();
LibJS: Constant fold `LogicalExpression` Logical expressions like `true || false` are now constant folded. This also allows for dead code elimination if we know the right-hand side of the expression will never be evaluated (such as `false && f()` or `true || f()`). In the test suites, the values are now being constant folded at compile time. To ensure that the actual evaluation logic is being called properly, I had to duplicate the tests and call them via a function so the compiler would not optimize the evaluation logic away. This also demotes `NaN` and `Infinity` identifiers to `nan` and `inf` double literals, which will further help with const folding.
2026-01-11 12:36:23 -08:00
if (rhs.operand().is_constant())
return rhs;
generator.emit_mov(dst, rhs);
return dst;
};
switch (expr->op()) {
case LogicalOp::And:
if (constant.to_boolean_slow_case())
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
return return_rhs();
LibJS: Constant fold `LogicalExpression` Logical expressions like `true || false` are now constant folded. This also allows for dead code elimination if we know the right-hand side of the expression will never be evaluated (such as `false && f()` or `true || f()`). In the test suites, the values are now being constant folded at compile time. To ensure that the actual evaluation logic is being called properly, I had to duplicate the tests and call them via a function so the compiler would not optimize the evaluation logic away. This also demotes `NaN` and `Infinity` identifiers to `nan` and `inf` double literals, which will further help with const folding.
2026-01-11 12:36:23 -08:00
return lhs;
case LogicalOp::Or:
if (constant.to_boolean_slow_case())
return lhs;
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
return return_rhs();
LibJS: Constant fold `LogicalExpression` Logical expressions like `true || false` are now constant folded. This also allows for dead code elimination if we know the right-hand side of the expression will never be evaluated (such as `false && f()` or `true || f()`). In the test suites, the values are now being constant folded at compile time. To ensure that the actual evaluation logic is being called properly, I had to duplicate the tests and call them via a function so the compiler would not optimize the evaluation logic away. This also demotes `NaN` and `Infinity` identifiers to `nan` and `inf` double literals, which will further help with const folding.
2026-01-11 12:36:23 -08:00
case LogicalOp::NullishCoalescing:
if (constant.is_nullish())
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
return return_rhs();
LibJS: Constant fold `LogicalExpression` Logical expressions like `true || false` are now constant folded. This also allows for dead code elimination if we know the right-hand side of the expression will never be evaluated (such as `false && f()` or `true || f()`). In the test suites, the values are now being constant folded at compile time. To ensure that the actual evaluation logic is being called properly, I had to duplicate the tests and call them via a function so the compiler would not optimize the evaluation logic away. This also demotes `NaN` and `Infinity` identifiers to `nan` and `inf` double literals, which will further help with const folding.
2026-01-11 12:36:23 -08:00
return lhs;
default:
VERIFY_NOT_REACHED();
}
return Optional<ScopedOperand> {};
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> LogicalExpression::generate_bytecode(Bytecode::Generator& generator, Optional<ScopedOperand> preferred_dst) const
LibJS: Implement bytecode ops for logical expressions
2021-06-08 02:18:47 +02:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto lhs = m_lhs->generate_bytecode(generator, preferred_dst).value();
LibJS: Constant fold `LogicalExpression` Logical expressions like `true || false` are now constant folded. This also allows for dead code elimination if we know the right-hand side of the expression will never be evaluated (such as `false && f()` or `true || f()`). In the test suites, the values are now being constant folded at compile time. To ensure that the actual evaluation logic is being called properly, I had to duplicate the tests and call them via a function so the compiler would not optimize the evaluation logic away. This also demotes `NaN` and `Infinity` identifiers to `nan` and `inf` double literals, which will further help with const folding.
2026-01-11 12:36:23 -08:00
// OPTIMIZATION: return lhs/rhs directly if we can detect lhs as a truthy/falsey literal
if (auto constant = generator.try_get_constant(lhs); constant.has_value()) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
return constant_fold_logical_expression(generator, preferred_dst, lhs, this);
LibJS: Constant fold `LogicalExpression` Logical expressions like `true || false` are now constant folded. This also allows for dead code elimination if we know the right-hand side of the expression will never be evaluated (such as `false && f()` or `true || f()`). In the test suites, the values are now being constant folded at compile time. To ensure that the actual evaluation logic is being called properly, I had to duplicate the tests and call them via a function so the compiler would not optimize the evaluation logic away. This also demotes `NaN` and `Infinity` identifiers to `nan` and `inf` double literals, which will further help with const folding.
2026-01-11 12:36:23 -08:00
}
LibJS: Implement bytecode ops for logical expressions
2021-06-08 02:18:47 +02:00
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
// lhs
// jump op (true) end (false) rhs
// rhs
// jump always (true) end
// end
LibJS: Constant fold `LogicalExpression` Logical expressions like `true || false` are now constant folded. This also allows for dead code elimination if we know the right-hand side of the expression will never be evaluated (such as `false && f()` or `true || f()`). In the test suites, the values are now being constant folded at compile time. To ensure that the actual evaluation logic is being called properly, I had to duplicate the tests and call them via a function so the compiler would not optimize the evaluation logic away. This also demotes `NaN` and `Infinity` identifiers to `nan` and `inf` double literals, which will further help with const folding.
2026-01-11 12:36:23 -08:00
auto dst = choose_dst(generator, preferred_dst);
generator.emit_mov(dst, lhs);
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
auto& rhs_block = generator.make_block();
auto& end_block = generator.make_block();
LibJS: Implement bytecode ops for logical expressions
2021-06-08 02:18:47 +02:00
switch (m_op) {
case LogicalOp::And:
LibJS/Bytecode: Do basic compare-and-jump peephole optimization We now fuse sequences like [LessThan, JumpIf] to JumpLessThan. This is only allowed for temporaries (i.e VM registers) with no other references to them.
2024-05-09 15:13:31 +02:00
generator.emit_jump_if(
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
lhs,
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
Bytecode::Label { rhs_block },
Bytecode::Label { end_block });
LibJS: Implement bytecode ops for logical expressions
2021-06-08 02:18:47 +02:00
break;
case LogicalOp::Or:
LibJS/Bytecode: Do basic compare-and-jump peephole optimization We now fuse sequences like [LessThan, JumpIf] to JumpLessThan. This is only allowed for temporaries (i.e VM registers) with no other references to them.
2024-05-09 15:13:31 +02:00
generator.emit_jump_if(
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
lhs,
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
Bytecode::Label { end_block },
Bytecode::Label { rhs_block });
LibJS: Implement bytecode ops for logical expressions
2021-06-08 02:18:47 +02:00
break;
case LogicalOp::NullishCoalescing:
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
generator.emit<Bytecode::Op::JumpNullish>(
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
lhs,
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
Bytecode::Label { rhs_block },
Bytecode::Label { end_block });
LibJS: Implement bytecode ops for logical expressions
2021-06-08 02:18:47 +02:00
break;
default:
VERIFY_NOT_REACHED();
}
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
generator.switch_to_basic_block(rhs_block);
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto rhs = m_rhs->generate_bytecode(generator, dst).value();
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(dst, rhs);
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { end_block });
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
generator.switch_to_basic_block(end_block);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return dst;
LibJS: Implement bytecode ops for logical expressions
2021-06-08 02:18:47 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> UnaryExpression::generate_bytecode(Bytecode::Generator& generator, Optional<ScopedOperand> preferred_dst) const
LibJS: Add bytecode instructions for a bunch of unary operators ~, !, +, -, typeof, and void.
2021-06-07 19:53:47 +01:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS/Bytecode: Turn UnaryMinus(NumericLiteral) into a constant
2024-05-09 19:48:25 +02:00
LibJS/Bytecode: Implement the delete unary expression `delete` has to operate directly on Reference Records, so this introduces a new set of operations called DeleteByValue, DeleteVariable and DeleteById. They operate similarly to their Get counterparts, except they end in creating a (temporary) Reference and calling delete_ on it.
2022-03-27 19:50:09 +01:00
if (m_op == UnaryOp::Delete)
return generator.emit_delete_reference(m_lhs);
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
Optional<ScopedOperand> src;
LibJS/Bytecode: Make typeof return "undefined" on unresolvable IDs Previously it would throw instead of returning "undefined" for `typeof Identifier` if Identifier does not exist.
2022-06-11 23:12:22 +01:00
// Typeof needs some special handling for when the LHS is an Identifier. Namely, it shouldn't throw on unresolvable references, but instead return "undefined".
LibJS: Optimize double boolean not (`!!`) operation This is a common way to convert a value to a boolean. Instead of doing a boolean conversion and 2 negate operations, we replace this with a single `ToBoolean` op code.
2026-01-06 16:03:23 -08:00
// Skip Not operator as it needs to be evaluated breadth first in order to detect `!!` optimization (otherwise the inner `!x` would eval first).
if (m_op != UnaryOp::Typeof && m_op != UnaryOp::Not)
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
src = m_lhs->generate_bytecode(generator).value();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
auto dst = choose_dst(generator, preferred_dst);
LibJS: Add bytecode instructions for a bunch of unary operators ~, !, +, -, typeof, and void.
2021-06-07 19:53:47 +01:00
LibJS: Optimize double boolean not (`!!`) operation This is a common way to convert a value to a boolean. Instead of doing a boolean conversion and 2 negate operations, we replace this with a single `ToBoolean` op code.
2026-01-06 16:03:23 -08:00
if (src.has_value()) {
if (auto result = try_constant_fold_unary_expression(generator, *src, m_op); result.has_value())
LibJS: Constant-fold unary expressions !0 and !1 are very common patterns in minified JavaScript, and we should figure out that they're constants. :^)
2025-03-25 18:01:35 +00:00
return result.release_value();
}
LibJS: Add bytecode instructions for a bunch of unary operators ~, !, +, -, typeof, and void.
2021-06-07 19:53:47 +01:00
switch (m_op) {
case UnaryOp::BitwiseNot:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::BitwiseNot>(dst, *src);
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
break;
LibJS: Add bytecode instructions for a bunch of unary operators ~, !, +, -, typeof, and void.
2021-06-07 19:53:47 +01:00
case UnaryOp::Not:
LibJS: Optimize double boolean not (`!!`) operation This is a common way to convert a value to a boolean. Instead of doing a boolean conversion and 2 negate operations, we replace this with a single `ToBoolean` op code.
2026-01-06 16:03:23 -08:00
if (auto nested = as_if<UnaryExpression>(*m_lhs); nested && nested->op() == UnaryOp::Not) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto value = nested->lhs()->generate_bytecode(generator).value();
LibJS: Optimize double boolean not (`!!`) operation This is a common way to convert a value to a boolean. Instead of doing a boolean conversion and 2 negate operations, we replace this with a single `ToBoolean` op code.
2026-01-06 16:03:23 -08:00
if (value.operand().is_constant())
return generator.add_constant(Value(generator.get_constant(value).to_boolean()));
generator.emit<Bytecode::Op::ToBoolean>(dst, value);
break;
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
src = m_lhs->generate_bytecode(generator).value();
LibJS: Optimize double boolean not (`!!`) operation This is a common way to convert a value to a boolean. Instead of doing a boolean conversion and 2 negate operations, we replace this with a single `ToBoolean` op code.
2026-01-06 16:03:23 -08:00
if (auto result = try_constant_fold_unary_expression(generator, *src, m_op); result.has_value())
return result.release_value();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::Not>(dst, *src);
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
break;
LibJS: Add bytecode instructions for a bunch of unary operators ~, !, +, -, typeof, and void.
2021-06-07 19:53:47 +01:00
case UnaryOp::Plus:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::UnaryPlus>(dst, *src);
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
break;
LibJS: Add bytecode instructions for a bunch of unary operators ~, !, +, -, typeof, and void.
2021-06-07 19:53:47 +01:00
case UnaryOp::Minus:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::UnaryMinus>(dst, *src);
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
break;
LibJS: Add bytecode instructions for a bunch of unary operators ~, !, +, -, typeof, and void.
2021-06-07 19:53:47 +01:00
case UnaryOp::Typeof:
LibJS/Bytecode: Make typeof return "undefined" on unresolvable IDs Previously it would throw instead of returning "undefined" for `typeof Identifier` if Identifier does not exist.
2022-06-11 23:12:22 +01:00
if (is<Identifier>(*m_lhs)) {
auto& identifier = static_cast<Identifier const&>(*m_lhs);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
if (!identifier.is_local()) {
LibJS/Bytecode: Rename TypeofVariable => TypeofBinding
2024-06-14 09:37:26 +02:00
generator.emit<Bytecode::Op::TypeofBinding>(dst, generator.intern_identifier(identifier.string()));
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
break;
LibJS: Update bytecode generator to use local variables - Update ECMAScriptFunctionObject::function_declaration_instantiation to initialize local variables - Introduce GetLocal, SetLocal, TypeofLocal that will be used to operate on local variables. - Update bytecode generator to emit instructions for local variables
2023-07-05 02:17:10 +02:00
}
LibJS/Bytecode: Make typeof return "undefined" on unresolvable IDs Previously it would throw instead of returning "undefined" for `typeof Identifier` if Identifier does not exist.
2022-06-11 23:12:22 +01:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
src = m_lhs->generate_bytecode(generator).value();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::Typeof>(dst, *src);
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
break;
LibJS: Add bytecode instructions for a bunch of unary operators ~, !, +, -, typeof, and void.
2021-06-07 19:53:47 +01:00
case UnaryOp::Void:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return generator.add_constant(js_undefined());
LibJS/Bytecode: Implement the delete unary expression `delete` has to operate directly on Reference Records, so this introduces a new set of operations called DeleteByValue, DeleteVariable and DeleteById. They operate similarly to their Get counterparts, except they end in creating a (temporary) Reference and calling delete_ on it.
2022-03-27 19:50:09 +01:00
case UnaryOp::Delete: // Delete is implemented above.
LibJS: Add bytecode instructions for a bunch of unary operators ~, !, +, -, typeof, and void.
2021-06-07 19:53:47 +01:00
default:
LibJS/Bytecode: Implement the delete unary expression `delete` has to operate directly on Reference Records, so this introduces a new set of operations called DeleteByValue, DeleteVariable and DeleteById. They operate similarly to their Get counterparts, except they end in creating a (temporary) Reference and calling delete_ on it.
2022-03-27 19:50:09 +01:00
VERIFY_NOT_REACHED();
LibJS: Add bytecode instructions for a bunch of unary operators ~, !, +, -, typeof, and void.
2021-06-07 19:53:47 +01:00
}
LibJS: Make ASTNode::generate_bytecode() fallible Instead of crashing on the spot, return a descriptive error that will eventually continue its days as a javascript "InternalError" exception. This should make random crashes with BC less likely.
2022-02-12 19:54:08 +03:30
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return dst;
LibJS: Add bytecode instructions for a bunch of unary operators ~, !, +, -, typeof, and void.
2021-06-07 19:53:47 +01:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> NumericLiteral::generate_bytecode(Bytecode::Generator& generator, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS/Bytecode: Make constant deduplication a bit smarter Instead of scanning through the list of seen constants, we now have a more structured storage of the constants true, false, null, undefined, and every possible Int32 value. This fixes an O(n^2) issue found by Kraken/json-stringify-tinderbox.js
2024-05-14 14:28:22 +02:00
return generator.add_constant(Value(m_value));
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> BooleanLiteral::generate_bytecode(Bytecode::Generator& generator, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS: Add bytecode ops for loading boolean and null values
2021-06-07 20:22:15 +02:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return generator.add_constant(Value(m_value));
LibJS: Add bytecode ops for loading boolean and null values
2021-06-07 20:22:15 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> NullLiteral::generate_bytecode(Bytecode::Generator& generator, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS: Add bytecode ops for loading boolean and null values
2021-06-07 20:22:15 +02:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return generator.add_constant(js_null());
LibJS: Add bytecode ops for loading boolean and null values
2021-06-07 20:22:15 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> BigIntLiteral::generate_bytecode(Bytecode::Generator& generator, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS: Implement bytecode generation for BigInts
2021-06-08 07:59:25 +02:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS: Support non-base-10 BigInt literals in bytecode VM Fixes 39 tests in test262 and a handful in test-js. :^)
2022-10-19 19:17:58 +02:00
// 1. Return the NumericValue of NumericLiteral as defined in 12.8.3.
auto integer = [&] {
if (m_value[0] == '0' && m_value.length() >= 3)
if (m_value[1] == 'x' || m_value[1] == 'X')
LibCrypto: Make constructing a BigInteger from string fallible Previously, constructing a `UnsignedBigInteger::from_base()` could produce an incorrect result if the input string contained a valid Base36 digit that was out of range of the given base. The same method would also crash if the input string contained an invalid Base36 digit. An error is now returned in both these cases. Constructing a BigFraction from string is now also fallible, so that we can handle the case where we are given an input string with invalid digits.
2024-01-12 21:34:23 +00:00
return MUST(Crypto::SignedBigInteger::from_base(16, m_value.substring(2, m_value.length() - 3)));
LibJS: Support non-base-10 BigInt literals in bytecode VM Fixes 39 tests in test262 and a handful in test-js. :^)
2022-10-19 19:17:58 +02:00
if (m_value[1] == 'o' || m_value[1] == 'O')
LibCrypto: Make constructing a BigInteger from string fallible Previously, constructing a `UnsignedBigInteger::from_base()` could produce an incorrect result if the input string contained a valid Base36 digit that was out of range of the given base. The same method would also crash if the input string contained an invalid Base36 digit. An error is now returned in both these cases. Constructing a BigFraction from string is now also fallible, so that we can handle the case where we are given an input string with invalid digits.
2024-01-12 21:34:23 +00:00
return MUST(Crypto::SignedBigInteger::from_base(8, m_value.substring(2, m_value.length() - 3)));
LibJS: Support non-base-10 BigInt literals in bytecode VM Fixes 39 tests in test262 and a handful in test-js. :^)
2022-10-19 19:17:58 +02:00
if (m_value[1] == 'b' || m_value[1] == 'B')
LibCrypto: Make constructing a BigInteger from string fallible Previously, constructing a `UnsignedBigInteger::from_base()` could produce an incorrect result if the input string contained a valid Base36 digit that was out of range of the given base. The same method would also crash if the input string contained an invalid Base36 digit. An error is now returned in both these cases. Constructing a BigFraction from string is now also fallible, so that we can handle the case where we are given an input string with invalid digits.
2024-01-12 21:34:23 +00:00
return MUST(Crypto::SignedBigInteger::from_base(2, m_value.substring(2, m_value.length() - 3)));
return MUST(Crypto::SignedBigInteger::from_base(10, m_value.substring(0, m_value.length() - 1)));
LibJS: Support non-base-10 BigInt literals in bytecode VM Fixes 39 tests in test262 and a handful in test-js. :^)
2022-10-19 19:17:58 +02:00
}();
LibJS/Bytecode: Make constant deduplication a bit smarter Instead of scanning through the list of seen constants, we now have a more structured storage of the constants true, false, null, undefined, and every possible Int32 value. This fixes an O(n^2) issue found by Kraken/json-stringify-tinderbox.js
2024-05-14 14:28:22 +02:00
return generator.add_constant(BigInt::create(generator.vm(), move(integer)));
LibJS: Implement bytecode generation for BigInts
2021-06-08 07:59:25 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> StringLiteral::generate_bytecode(Bytecode::Generator& generator, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS/Bytecode: Make constant deduplication a bit smarter Instead of scanning through the list of seen constants, we now have a more structured storage of the constants true, false, null, undefined, and every possible Int32 value. This fixes an O(n^2) issue found by Kraken/json-stringify-tinderbox.js
2024-05-14 14:28:22 +02:00
return generator.add_constant(PrimitiveString::create(generator.vm(), m_value));
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> RegExpLiteral::generate_bytecode(Bytecode::Generator& generator, Optional<ScopedOperand> preferred_dst) const
LibJS: Add bytecode support for regexp literals
2021-06-19 17:17:40 -07:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS+LibWeb: Port interned bytecode strings to UTF-16 This was almost a no-op, except we intern JS exception messages. So the bulk of this patch is porting exception messages to UTF-16.
2025-08-07 19:31:52 -04:00
auto source_index = generator.intern_string(m_pattern);
auto flags_index = generator.intern_string(m_flags);
LibJS/Bytecode: Don't reparse regular expressions on instantiation The RegExpLiteral AST node already has the parsed regex::Parser::Result so let's plumb that over to the bytecode executable instead of reparsing the regex every time NewRegExp is executed. ~12% speed-up on language/literals/regexp/S7.8.5_A2.1_T2.js in test262.
2023-07-13 10:49:07 +02:00
auto regex_index = generator.intern_regex(Bytecode::ParsedRegex {
.regex = m_parsed_regex,
.pattern = m_parsed_pattern,
.flags = m_parsed_flags,
});
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
auto dst = choose_dst(generator, preferred_dst);
generator.emit<Bytecode::Op::NewRegExp>(dst, source_index, flags_index, regex_index);
return dst;
LibJS: Add bytecode support for regexp literals
2021-06-19 17:17:40 -07:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> Identifier::generate_bytecode(Bytecode::Generator& generator, Optional<ScopedOperand> preferred_dst) const
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
if (is_local()) {
LibJS: Consolidate TDZ check emission into Generator helper Move the duplicated ThrowIfTDZ emission logic from three places in ASTCodegen.cpp into a single Generator::emit_tdz_check_if_needed() helper. This handles both argument TDZ (which requires a Mov to empty first) and lexically-declared variable TDZ uniformly. This avoids emitting some unnecessary ThrowIfTDZ instructions.
2026-02-17 17:42:14 +01:00
generator.emit_tdz_check_if_needed(*this);
return generator.local(local_index());
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
}
LibJS: Introduce NativeJavaScriptBackedFunction This hosts the ability to compile and run JavaScript to implement native functions. This is particularly useful for any native function that is not a normal function, for example async functions such as Array.fromAsync, which require yielding. These functions are not allowed to observe anything from outside their environment. Any global identifiers will instead be assumed to be a reference to an abstract operation or a constant. The generator will inject the appropriate bytecode if the name of the global identifier matches a known name. Anything else will cause a code generation error.
2025-11-06 19:00:36 +00:00
if (is_global()) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto maybe_constant = generator.maybe_generate_builtin_constant(*this);
LibJS: Introduce NativeJavaScriptBackedFunction This hosts the ability to compile and run JavaScript to implement native functions. This is particularly useful for any native function that is not a normal function, for example async functions such as Array.fromAsync, which require yielding. These functions are not allowed to observe anything from outside their environment. Any global identifiers will instead be assumed to be a reference to an abstract operation or a constant. The generator will inject the appropriate bytecode if the name of the global identifier matches a known name. Anything else will cause a code generation error.
2025-11-06 19:00:36 +00:00
if (maybe_constant.has_value())
return maybe_constant.release_value();
LibJS/Bytecode: Don't emit `GetGlobal undefined` We know that `undefined` in the global scope is always the proper undefined value. This commit takes advantage of that by simply emitting a constant undefined value instead. Unfortunately we can't be so sure in other scopes.
2024-05-09 15:21:24 +02:00
}
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
auto dst = choose_dst(generator, preferred_dst);
LibJS: Add optimized GetGlobal instruction to access global variables Using a special instruction to access global variables allows skipping the environment chain traversal for them and going directly to the module/global environment. Currently, this instruction only caches the offset for bindings that belong to the global object environment. However, there is also an opportunity to cache the offset in the global declarative record. This change results in a 57% increase in speed for imaging-gaussian-blur.js in Kraken.
2023-07-12 04:06:59 +02:00
if (is_global()) {
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::GetGlobal>(dst, generator.intern_identifier(m_string), generator.next_global_variable_cache());
LibJS: Update bytecode generator to use local variables - Update ECMAScriptFunctionObject::function_declaration_instantiation to initialize local variables - Introduce GetLocal, SetLocal, TypeofLocal that will be used to operate on local variables. - Update bytecode generator to emit instructions for local variables
2023-07-05 02:17:10 +02:00
} else {
LibJS: Optimize reading known-to-be-initialized `var` bindings `var` bindings are never in the temporal dead zone (TDZ), and so we know accessing them will not throw. We now take advantage of this by having a specialized environment binding value getter that doesn't check for exceptional cases. 1.08x speedup on JetStream.
2025-05-04 01:41:49 +02:00
if (declaration_kind() == DeclarationKind::Var) {
generator.emit<Bytecode::Op::GetInitializedBinding>(dst, generator.intern_identifier(m_string));
} else {
generator.emit<Bytecode::Op::GetBinding>(dst, generator.intern_identifier(m_string));
}
LibJS: Update bytecode generator to use local variables - Update ECMAScriptFunctionObject::function_declaration_instantiation to initialize local variables - Introduce GetLocal, SetLocal, TypeofLocal that will be used to operate on local variables. - Update bytecode generator to emit instructions for local variables
2023-07-05 02:17:10 +02:00
}
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return dst;
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
static Optional<ScopedOperand> arguments_to_array_for_call(Bytecode::Generator& generator, ReadonlySpan<CallExpression::Argument> arguments)
LibJS: Handle argument spreading in the bytecode vm
2022-09-09 16:05:40 +02:00
{
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto dst = generator.allocate_register();
LibJS: Handle argument spreading in the bytecode vm
2022-09-09 16:05:40 +02:00
if (arguments.is_empty()) {
LibJS: Generate C++ bytecode instruction classes from a definition file This commit adds a new Bytecode.def file that describes all the LibJS bytecode instructions. From this, we are able to generate the full declarations for all C++ bytecode instruction classes, as well as their serialization code. Note that some of the bytecode compiler was updated since instructions no longer have default constructor arguments. The big immediate benefit here is that we lose a couple thousand lines of hand-written C++ code. Going forward, this also allows us to do more tooling for the bytecode VM, now that we have an authoritative description of its instructions. Key things to know about: - Instructions can inherit from one another. At the moment, everything simply inherits from the base "Instruction". - @terminator means the instruction terminates a basic block. - @nothrow means the instruction cannot throw. This affects how the interpreter interacts with it. - Variable-length instructions are automatically supported. Just put an array of something as the last field of the instruction. - The m_length field is magical. If present, it will be populated with the full length of the instruction. This is used for variable-length instructions.
2025-11-20 22:14:50 +01:00
generator.emit<Bytecode::Op::NewArray>(dst, ReadonlySpan<ScopedOperand> {});
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return dst;
LibJS: Handle argument spreading in the bytecode vm
2022-09-09 16:05:40 +02:00
}
auto first_spread = find_if(arguments.begin(), arguments.end(), [](auto el) { return el.is_spread; });
LibJS/Bytecode: Make NewArray a variable-length instruction This removes a layer of indirection in the bytecode where we had to make sure all the initializer elements were laid out in sequential registers. Array expressions no longer clobber registers permanently, and they can be reused immediately afterwards.
2024-05-08 12:43:08 +02:00
Vector<ScopedOperand> args;
args.ensure_capacity(first_spread.index());
LibJS: Handle argument spreading in the bytecode vm
2022-09-09 16:05:40 +02:00
for (auto it = arguments.begin(); it != first_spread; ++it) {
LibJS/Bytecode: Make NewArray a variable-length instruction This removes a layer of indirection in the bytecode where we had to make sure all the initializer elements were laid out in sequential registers. Array expressions no longer clobber registers permanently, and they can be reused immediately afterwards.
2024-05-08 12:43:08 +02:00
VERIFY(!it->is_spread);
auto reg = generator.allocate_register();
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto value = it->value->generate_bytecode(generator).value();
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(reg, value);
LibJS/Bytecode: Make NewArray a variable-length instruction This removes a layer of indirection in the bytecode where we had to make sure all the initializer elements were laid out in sequential registers. Array expressions no longer clobber registers permanently, and they can be reused immediately afterwards.
2024-05-08 12:43:08 +02:00
args.append(move(reg));
LibJS: Handle argument spreading in the bytecode vm
2022-09-09 16:05:40 +02:00
}
if (first_spread.index() != 0)
LibJS: Generate C++ bytecode instruction classes from a definition file This commit adds a new Bytecode.def file that describes all the LibJS bytecode instructions. From this, we are able to generate the full declarations for all C++ bytecode instruction classes, as well as their serialization code. Note that some of the bytecode compiler was updated since instructions no longer have default constructor arguments. The big immediate benefit here is that we lose a couple thousand lines of hand-written C++ code. Going forward, this also allows us to do more tooling for the bytecode VM, now that we have an authoritative description of its instructions. Key things to know about: - Instructions can inherit from one another. At the moment, everything simply inherits from the base "Instruction". - @terminator means the instruction terminates a basic block. - @nothrow means the instruction cannot throw. This affects how the interpreter interacts with it. - Variable-length instructions are automatically supported. Just put an array of something as the last field of the instruction. - The m_length field is magical. If present, it will be populated with the full length of the instruction. This is used for variable-length instructions.
2025-11-20 22:14:50 +01:00
generator.emit_with_extra_operand_slots<Bytecode::Op::NewArray>(args.size(), dst, args.span());
LibJS: Handle argument spreading in the bytecode vm
2022-09-09 16:05:40 +02:00
else
LibJS: Generate C++ bytecode instruction classes from a definition file This commit adds a new Bytecode.def file that describes all the LibJS bytecode instructions. From this, we are able to generate the full declarations for all C++ bytecode instruction classes, as well as their serialization code. Note that some of the bytecode compiler was updated since instructions no longer have default constructor arguments. The big immediate benefit here is that we lose a couple thousand lines of hand-written C++ code. Going forward, this also allows us to do more tooling for the bytecode VM, now that we have an authoritative description of its instructions. Key things to know about: - Instructions can inherit from one another. At the moment, everything simply inherits from the base "Instruction". - @terminator means the instruction terminates a basic block. - @nothrow means the instruction cannot throw. This affects how the interpreter interacts with it. - Variable-length instructions are automatically supported. Just put an array of something as the last field of the instruction. - The m_length field is magical. If present, it will be populated with the full length of the instruction. This is used for variable-length instructions.
2025-11-20 22:14:50 +01:00
generator.emit<Bytecode::Op::NewArray>(dst, ReadonlySpan<ScopedOperand> {});
LibJS: Handle argument spreading in the bytecode vm
2022-09-09 16:05:40 +02:00
if (first_spread != arguments.end()) {
for (auto it = first_spread; it != arguments.end(); ++it) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto value = it->value->generate_bytecode(generator).value();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::ArrayAppend>(dst, value, it->is_spread);
LibJS: Handle argument spreading in the bytecode vm
2022-09-09 16:05:40 +02:00
}
}
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return dst;
LibJS: Handle argument spreading in the bytecode vm
2022-09-09 16:05:40 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> SuperCall::generate_bytecode(Bytecode::Generator& generator, Optional<ScopedOperand> preferred_dst) const
LibJS: Implement SuperCall for the Bytecode-VM
2022-08-30 18:03:02 +02:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
Optional<ScopedOperand> arguments;
LibJS: Implement SuperCall for the Bytecode-VM
2022-08-30 18:03:02 +02:00
if (m_is_synthetic == IsPartOfSyntheticConstructor::Yes) {
// NOTE: This is the case where we have a fake constructor(...args) { super(...args); } which
// shouldn't call @@iterator of %Array.prototype%.
VERIFY(m_arguments.size() == 1);
VERIFY(m_arguments[0].is_spread);
auto const& argument = m_arguments[0];
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
// This generates a single argument.
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
arguments = argument.value->generate_bytecode(generator);
LibJS: Implement SuperCall for the Bytecode-VM
2022-08-30 18:03:02 +02:00
} else {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
arguments = arguments_to_array_for_call(generator, m_arguments).value();
LibJS: Implement SuperCall for the Bytecode-VM
2022-08-30 18:03:02 +02:00
}
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
auto dst = choose_dst(generator, preferred_dst);
generator.emit<Bytecode::Op::SuperCallWithArgumentArray>(dst, *arguments, m_is_synthetic == IsPartOfSyntheticConstructor::Yes);
return dst;
LibJS: Implement SuperCall for the Bytecode-VM
2022-08-30 18:03:02 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> AssignmentExpression::generate_bytecode(Bytecode::Generator& generator, Optional<ScopedOperand> preferred_dst) const
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
if (m_op == AssignmentOp::Assignment) {
LibJS/Bytecode: Evaluate LHS of assignment before RHS We had the same issue with the AST interpreter, see issue #3689.
2022-07-17 19:23:52 +01:00
// AssignmentExpression : LeftHandSideExpression = AssignmentExpression
return m_lhs.visit(
// 1. If LeftHandSideExpression is neither an ObjectLiteral nor an ArrayLiteral, then
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
[&](NonnullRefPtr<Expression const> const& lhs) -> Optional<ScopedOperand> {
LibJS/Bytecode: Evaluate LHS of assignment before RHS We had the same issue with the AST interpreter, see issue #3689.
2022-07-17 19:23:52 +01:00
// a. Let lref be the result of evaluating LeftHandSideExpression.
// b. ReturnIfAbrupt(lref).
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
Optional<ScopedOperand> base;
Optional<ScopedOperand> computed_property;
Optional<ScopedOperand> this_value;
LibJS/Bytecode: Use proper `this` for receiver in get/set for super expr Summary: Diff Tests: +14 ✅ -2 ❌ -12 📝
2023-07-02 19:26:31 +01:00
bool lhs_is_super_expression = false;
LibJS/Bytecode: Evaluate LHS of assignment before RHS We had the same issue with the AST interpreter, see issue #3689.
2022-07-17 19:23:52 +01:00
if (is<MemberExpression>(*lhs)) {
auto& expression = static_cast<MemberExpression const&>(*lhs);
LibJS/Bytecode: Use proper `this` for receiver in get/set for super expr Summary: Diff Tests: +14 ✅ -2 ❌ -12 📝
2023-07-02 19:26:31 +01:00
lhs_is_super_expression = is<SuperExpression>(expression.object());
if (!lhs_is_super_expression) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto generated_base = expression.object().generate_bytecode(generator).value();
LibJS: Copy base object of LHS of assignment to preserve eval order Previously, the given test would create an object with the test property that pointed to itself. This is because `temp = temp.test || {}` overwrote the `temp` local register, and `temp.test = temp` used the new object instead of the original one it fetched. Allows https://www.yorkshiretea.co.uk/ to load, which was failing in Gsap library initialization.
2025-09-01 15:38:42 +01:00
base = generator.copy_if_needed_to_preserve_evaluation_order(generated_base);
LibJS/Bytecode: Use proper `this` for receiver in get/set for super expr Summary: Diff Tests: +14 ✅ -2 ❌ -12 📝
2023-07-02 19:26:31 +01:00
} else {
// https://tc39.es/ecma262/#sec-super-keyword-runtime-semantics-evaluation
// 1. Let env be GetThisEnvironment().
// 2. Let actualThis be ? env.GetThisBinding().
LibJS/Bytecode: Only emit ResolveThisBinding once per basic block Once executed, this instruction will always produce the same result in subsequent executions, so it's okay to cache it. Unfortunately it may throw, so we can't just hoist it to the top of every executable, since that would break observable execution order.
2024-05-07 12:16:37 +02:00
this_value = generator.get_this();
LibJS/Bytecode: Use proper `this` for receiver in get/set for super expr Summary: Diff Tests: +14 ✅ -2 ❌ -12 📝
2023-07-02 19:26:31 +01:00
// SuperProperty : super [ Expression ]
// 3. Let propertyNameReference be ? Evaluation of Expression.
// 4. Let propertyNameValue be ? GetValue(propertyNameReference).
}
LibJS/Bytecode: Evaluate LHS of assignment before RHS We had the same issue with the AST interpreter, see issue #3689.
2022-07-17 19:23:52 +01:00
if (expression.is_computed()) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto property = expression.property().generate_bytecode(generator).value();
LibJS/Bytecode: Add and use copy_if_needed_to_preserve_evaluation_order This is a new Bytecode::Generator helper that takes an operand and returns the same operand, or a copy of it, in case a copy is required to preserve correct evaluation order. This can be used in a bunch of places where we're worried about clobbering some value after obtaining it. Practically, locals are always copied, and temporary registers as well as constants are returned as-is.
2024-06-01 10:00:32 +02:00
computed_property = generator.copy_if_needed_to_preserve_evaluation_order(property);
LibJS/Bytecode: Evaluate LHS of assignment before RHS We had the same issue with the AST interpreter, see issue #3689.
2022-07-17 19:23:52 +01:00
// To be continued later with PutByValue.
} else if (expression.property().is_identifier()) {
// Do nothing, this will be handled by PutById later.
LibJS/Bytecode: Support private class fields This is accomplished with two new instructions: - GetPrivateById - PutPrivateById Looks like 1616 new passes on test262. :^)
2023-06-23 08:16:17 +02:00
} else if (expression.property().is_private_identifier()) {
// Do nothing, this will be handled by PutPrivateById later.
LibJS/Bytecode: Evaluate LHS of assignment before RHS We had the same issue with the AST interpreter, see issue #3689.
2022-07-17 19:23:52 +01:00
} else {
LibJS: Convert unreachable codegen error sites to VERIFY Replace CodeGenerationError returns with VERIFY_NOT_REACHED() or VERIFY() at sites that are provably unreachable: - Non-computed member expression fallbacks in emit_load_from_reference, emit_store_to_reference, and emit_delete_reference (member expression properties are always computed, identifier, or private identifier) - Two non-computed member expression fallbacks in AssignmentExpression - Default case in compound assignment switch (all 15 AssignmentOp values are handled) - BindingPattern Empty/Expression name+alias pair (computed property names always require an alias) - Two assignment+destructuring combinations in for-in/of body evaluation (is_destructuring is only set for VariableDeclaration lhs, which always has VarBinding or LexicalBinding kind, never Assignment)
2026-02-11 22:05:55 +01:00
VERIFY_NOT_REACHED();
LibJS/Bytecode: Evaluate LHS of assignment before RHS We had the same issue with the AST interpreter, see issue #3689.
2022-07-17 19:23:52 +01:00
}
LibJS/Bytecode: Use proper `this` for receiver in get/set for super expr Summary: Diff Tests: +14 ✅ -2 ❌ -12 📝
2023-07-02 19:26:31 +01:00
if (lhs_is_super_expression) {
// 5/7. Return ? MakeSuperPropertyReference(actualThis, propertyKey, strict).
// https://tc39.es/ecma262/#sec-makesuperpropertyreference
// 1. Let env be GetThisEnvironment().
// 2. Assert: env.HasSuperBinding() is true.
// 3. Let baseValue be ? env.GetSuperBase().
// 4. Return the Reference Record { [[Base]]: baseValue, [[ReferencedName]]: propertyKey, [[Strict]]: strict, [[ThisValue]]: actualThis }.
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
base = generator.allocate_register();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::ResolveSuperBase>(*base);
LibJS/Bytecode: Use proper `this` for receiver in get/set for super expr Summary: Diff Tests: +14 ✅ -2 ❌ -12 📝
2023-07-02 19:26:31 +01:00
}
LibJS/Bytecode: Evaluate LHS of assignment before RHS We had the same issue with the AST interpreter, see issue #3689.
2022-07-17 19:23:52 +01:00
} else if (is<Identifier>(*lhs)) {
LibJS/Bytecode: Rename GetVariable => GetBinding
2024-05-14 11:32:04 +02:00
// NOTE: For Identifiers, we cannot perform GetBinding and then write into the reference it retrieves, only SetVariable can do this.
LibJS/Bytecode: Evaluate LHS of assignment before RHS We had the same issue with the AST interpreter, see issue #3689.
2022-07-17 19:23:52 +01:00
// FIXME: However, this breaks spec as we are doing variable lookup after evaluating the RHS. This is observable in an object environment, where we visibly perform HasOwnProperty and Get(@@unscopables) on the binded object.
} else {
LibJS: Throw ReferenceError for invalid assignment targets like foo()=x CallExpression is accepted as an assignment target for web compatibility (Annex B), but must throw ReferenceError at runtime. We were incorrectly throwing TypeError with a TODO message. Replace emit_todo() calls in three codegen paths (simple assignment, compound assignment/update, and for-in/of) with proper ReferenceError using the "Invalid left-hand side in assignment" message, matching the behavior of V8 and JSC.
2026-02-11 23:22:50 +01:00
// Per spec 13.15.2 step 1b, we must evaluate the LHS (the call),
// then throw ReferenceError before evaluating the RHS.
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
(void)lhs->generate_bytecode(generator);
LibJS: Throw ReferenceError for invalid assignment targets like foo()=x CallExpression is accepted as an assignment target for web compatibility (Annex B), but must throw ReferenceError at runtime. We were incorrectly throwing TypeError with a TODO message. Replace emit_todo() calls in three codegen paths (simple assignment, compound assignment/update, and for-in/of) with proper ReferenceError using the "Invalid left-hand side in assignment" message, matching the behavior of V8 and JSC.
2026-02-11 23:22:50 +01:00
auto exception = generator.allocate_register();
generator.emit<Bytecode::Op::NewReferenceError>(exception, generator.intern_string(ErrorType::InvalidLeftHandAssignment.message()));
generator.perform_needed_unwinds<Bytecode::Op::Throw>();
generator.emit<Bytecode::Op::Throw>(exception);
LibJS: Don't emit dead code after Throw for invalid LHS expressions When the left-hand side of an assignment, update, or for-in loop is invalid (e.g. `foo() = "bar"`), the bytecode generator emits a Throw instruction. Previously, it would also create a dead basic block after the Throw, resulting in unreachable instructions in the output. Fix this by returning early from the relevant codegen paths after emitting the Throw, and by guarding for-in/for-of body generation with an is_current_block_terminated() check.
2026-03-01 13:17:26 +01:00
return {};
LibJS/Bytecode: Evaluate LHS of assignment before RHS We had the same issue with the AST interpreter, see issue #3689.
2022-07-17 19:23:52 +01:00
}
LibJS: Remove stale FIXME about NamedEvaluation in assignment The FIXME claimed that IsAnonymousFunctionDefinition + NamedEvaluation was missing for simple assignment expressions like `x = function() {}`. However, the code directly below the FIXME already implements this correctly via emit_named_evaluation_if_anonymous_function.
2026-02-08 12:03:15 +01:00
// c. If IsAnonymousFunctionDefinition(AssignmentExpression) and IsIdentifierRef of LeftHandSideExpression are both true, then
// i. Let rval be ? NamedEvaluation of AssignmentExpression with argument lref.[[ReferencedName]].
LibJS/Bytecode: Evaluate LHS of assignment before RHS We had the same issue with the AST interpreter, see issue #3689.
2022-07-17 19:23:52 +01:00
// d. Else,
LibJS: Remove stale FIXME about NamedEvaluation in assignment The FIXME claimed that IsAnonymousFunctionDefinition + NamedEvaluation was missing for simple assignment expressions like `x = function() {}`. However, the code directly below the FIXME already implements this correctly via emit_named_evaluation_if_anonymous_function.
2026-02-08 12:03:15 +01:00
// i. Let rref be the result of evaluating AssignmentExpression.
// ii. Let rval be ? GetValue(rref).
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto rval = [&]() -> ScopedOperand {
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
if (lhs->is_identifier()) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
return generator.emit_named_evaluation_if_anonymous_function(*m_rhs, generator.intern_identifier(static_cast<Identifier const&>(*lhs).string()));
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
} else {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
return m_rhs->generate_bytecode(generator).value();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
}();
LibJS/Bytecode: Evaluate LHS of assignment before RHS We had the same issue with the AST interpreter, see issue #3689.
2022-07-17 19:23:52 +01:00
// e. Perform ? PutValue(lref, rval).
if (is<Identifier>(*lhs)) {
auto& identifier = static_cast<Identifier const&>(*lhs);
LibJS: Consolidate TDZ check emission into Generator helper Move the duplicated ThrowIfTDZ emission logic from three places in ASTCodegen.cpp into a single Generator::emit_tdz_check_if_needed() helper. This handles both argument TDZ (which requires a Mov to empty first) and lexically-declared variable TDZ uniformly. This avoids emitting some unnecessary ThrowIfTDZ instructions.
2026-02-17 17:42:14 +01:00
if (identifier.is_local())
generator.emit_tdz_check_if_needed(identifier);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit_set_variable(identifier, rval);
LibJS/Bytecode: Evaluate LHS of assignment before RHS We had the same issue with the AST interpreter, see issue #3689.
2022-07-17 19:23:52 +01:00
} else if (is<MemberExpression>(*lhs)) {
auto& expression = static_cast<MemberExpression const&>(*lhs);
LibJS: Include identifier information in nullish property write access When a PutById / PutByValue bytecode operation results in accessing a nullish object, we now include the name of the property and the object being accessed in the exception message (if available). This should make it easier to debug live websites. For example, the following errors would all previously produce a generic error message of "ToObject on null or undefined": > foo = null > foo.bar = 1 Uncaught exception: [TypeError] Cannot access property "bar" on null object "foo" at <unknown> > foo = { bar: undefined } > foo.bar.baz = 1 Uncaught exception: [TypeError] Cannot access property "baz" on undefined object "foo.bar" at <unknown> Note we certainly don't capture all possible nullish property write accesses here. This just covers cases I've seen most on live websites; we can cover more cases as they arise.
2024-03-29 12:10:52 -04:00
auto base_identifier = generator.intern_identifier_for_expression(expression.object());
LibJS/Bytecode: Evaluate LHS of assignment before RHS We had the same issue with the AST interpreter, see issue #3689.
2022-07-17 19:23:52 +01:00
if (expression.is_computed()) {
LibJS/Bytecode: Use proper `this` for receiver in get/set for super expr Summary: Diff Tests: +14 ✅ -2 ❌ -12 📝
2023-07-02 19:26:31 +01:00
if (!lhs_is_super_expression)
LibJS: Rename Bytecode::Op::PropertyKind => Bytecode::PutKind This is only used to specify how a property is being added to an object by Put* instructions, so let's call it PutKind. Also add an enumeration X macro for it to prepare for upcoming specializations.
2025-10-10 11:16:02 +02:00
generator.emit_put_by_value(*base, *computed_property, rval, Bytecode::PutKind::Normal, move(base_identifier));
LibJS/Bytecode: Use proper `this` for receiver in get/set for super expr Summary: Diff Tests: +14 ✅ -2 ❌ -12 📝
2023-07-02 19:26:31 +01:00
else
LibJS: Rename Bytecode::Op::PropertyKind => Bytecode::PutKind This is only used to specify how a property is being added to an object by Put* instructions, so let's call it PutKind. Also add an enumeration X macro for it to prepare for upcoming specializations.
2025-10-10 11:16:02 +02:00
generator.emit_put_by_value_with_this(*base, *computed_property, *this_value, rval, PutKind::Normal);
LibJS/Bytecode: Evaluate LHS of assignment before RHS We had the same issue with the AST interpreter, see issue #3689.
2022-07-17 19:23:52 +01:00
} else if (expression.property().is_identifier()) {
LibJS: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
auto property_key_table_index = generator.intern_property_key(as<Identifier>(expression.property()).string());
LibJS/Bytecode: Use proper `this` for receiver in get/set for super expr Summary: Diff Tests: +14 ✅ -2 ❌ -12 📝
2023-07-02 19:26:31 +01:00
if (!lhs_is_super_expression)
LibJS: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
generator.emit_put_by_id(*base, property_key_table_index, rval, Bytecode::PutKind::Normal, generator.next_property_lookup_cache(), move(base_identifier));
LibJS/Bytecode: Use proper `this` for receiver in get/set for super expr Summary: Diff Tests: +14 ✅ -2 ❌ -12 📝
2023-07-02 19:26:31 +01:00
else
LibJS: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
generator.emit<Bytecode::Op::PutNormalByIdWithThis>(*base, *this_value, property_key_table_index, rval, generator.next_property_lookup_cache());
LibJS/Bytecode: Support private class fields This is accomplished with two new instructions: - GetPrivateById - PutPrivateById Looks like 1616 new passes on test262. :^)
2023-06-23 08:16:17 +02:00
} else if (expression.property().is_private_identifier()) {
AK+Everywhere: Rename `verify_cast` to `as` Follow-up to fc20e61e7249006247b43f84a3189d5a37fa103e.
2025-01-21 09:12:05 -05:00
auto identifier_table_ref = generator.intern_identifier(as<PrivateIdentifier>(expression.property()).string());
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::PutPrivateById>(*base, identifier_table_ref, rval);
LibJS/Bytecode: Evaluate LHS of assignment before RHS We had the same issue with the AST interpreter, see issue #3689.
2022-07-17 19:23:52 +01:00
} else {
LibJS: Convert unreachable codegen error sites to VERIFY Replace CodeGenerationError returns with VERIFY_NOT_REACHED() or VERIFY() at sites that are provably unreachable: - Non-computed member expression fallbacks in emit_load_from_reference, emit_store_to_reference, and emit_delete_reference (member expression properties are always computed, identifier, or private identifier) - Two non-computed member expression fallbacks in AssignmentExpression - Default case in compound assignment switch (all 15 AssignmentOp values are handled) - BindingPattern Empty/Expression name+alias pair (computed property names always require an alias) - Two assignment+destructuring combinations in for-in/of body evaluation (is_destructuring is only set for VariableDeclaration lhs, which always has VarBinding or LexicalBinding kind, never Assignment)
2026-02-11 22:05:55 +01:00
VERIFY_NOT_REACHED();
LibJS/Bytecode: Evaluate LHS of assignment before RHS We had the same issue with the AST interpreter, see issue #3689.
2022-07-17 19:23:52 +01:00
}
} else {
LibJS: Remove emit_todo() from AssignmentExpression codegen The else branch already throws ReferenceError and switches to a dead basic block, so the emit_todo() in the PutValue section is unreachable. Return early after the throw and replace emit_todo() with VERIFY_NOT_REACHED().
2026-02-12 00:57:59 +01:00
VERIFY_NOT_REACHED();
LibJS/Bytecode: Evaluate LHS of assignment before RHS We had the same issue with the AST interpreter, see issue #3689.
2022-07-17 19:23:52 +01:00
}
// f. Return rval.
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return rval;
LibJS/Bytecode: Evaluate LHS of assignment before RHS We had the same issue with the AST interpreter, see issue #3689.
2022-07-17 19:23:52 +01:00
},
// 2. Let assignmentPattern be the AssignmentPattern that is covered by LeftHandSideExpression.
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
[&](NonnullRefPtr<BindingPattern const> const& pattern) -> Optional<ScopedOperand> {
LibJS/Bytecode: Implement destructuring assignment
2022-07-17 19:24:37 +01:00
// 3. Let rref be the result of evaluating AssignmentExpression.
// 4. Let rval be ? GetValue(rref).
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto rval = m_rhs->generate_bytecode(generator).value();
LibJS/Bytecode: Implement destructuring assignment
2022-07-17 19:24:37 +01:00
// 5. Perform ? DestructuringAssignmentEvaluation of assignmentPattern with argument rval.
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
pattern->generate_bytecode(generator, Bytecode::Op::BindingInitializationMode::Set, rval);
LibJS/Bytecode: Implement destructuring assignment
2022-07-17 19:24:37 +01:00
// 6. Return rval.
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return rval;
LibJS/Bytecode: Evaluate LHS of assignment before RHS We had the same issue with the AST interpreter, see issue #3689.
2022-07-17 19:23:52 +01:00
});
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
}
LibJS: Add support for various assignment operators
2021-06-07 20:12:38 +01:00
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
VERIFY(m_lhs.has<NonnullRefPtr<Expression const>>());
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
auto& lhs_expression = m_lhs.get<NonnullRefPtr<Expression const>>();
LibJS/Bytecode: Evaluate LHS of assignment before RHS We had the same issue with the AST interpreter, see issue #3689.
2022-07-17 19:23:52 +01:00
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto reference_operands = generator.emit_load_from_reference(lhs_expression);
LibJS: Don't emit dead code after Throw for invalid LHS expressions When the left-hand side of an assignment, update, or for-in loop is invalid (e.g. `foo() = "bar"`), the bytecode generator emits a Throw instruction. Previously, it would also create a dead basic block after the Throw, resulting in unreachable instructions in the output. Fix this by returning early from the relevant codegen paths after emitting the Throw, and by guarding for-in/for-of body generation with an is_current_block_terminated() check.
2026-03-01 13:17:26 +01:00
if (!reference_operands.loaded_value.has_value())
return {};
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
auto lhs = reference_operands.loaded_value.value();
LibJS: Add support for various assignment operators
2021-06-07 20:12:38 +01:00
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
Bytecode::BasicBlock* rhs_block_ptr { nullptr };
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
Bytecode::BasicBlock* lhs_block_ptr { nullptr };
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
Bytecode::BasicBlock* end_block_ptr { nullptr };
LibJS: Add support for various assignment operators
2021-06-07 20:12:38 +01:00
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
// Logical assignments short circuit.
if (m_op == AssignmentOp::AndAssignment) { // &&=
rhs_block_ptr = &generator.make_block();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
lhs_block_ptr = &generator.make_block();
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
end_block_ptr = &generator.make_block();
LibJS: Add logical assignment bytecode generation
2021-06-09 21:14:31 +01:00
LibJS/Bytecode: Do basic compare-and-jump peephole optimization We now fuse sequences like [LessThan, JumpIf] to JumpLessThan. This is only allowed for temporaries (i.e VM registers) with no other references to them.
2024-05-09 15:13:31 +02:00
generator.emit_jump_if(
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
lhs,
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
Bytecode::Label { *rhs_block_ptr },
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
Bytecode::Label { *lhs_block_ptr });
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
} else if (m_op == AssignmentOp::OrAssignment) { // ||=
rhs_block_ptr = &generator.make_block();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
lhs_block_ptr = &generator.make_block();
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
end_block_ptr = &generator.make_block();
LibJS: Add logical assignment bytecode generation
2021-06-09 21:14:31 +01:00
LibJS/Bytecode: Do basic compare-and-jump peephole optimization We now fuse sequences like [LessThan, JumpIf] to JumpLessThan. This is only allowed for temporaries (i.e VM registers) with no other references to them.
2024-05-09 15:13:31 +02:00
generator.emit_jump_if(
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
lhs,
Bytecode::Label { *lhs_block_ptr },
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
Bytecode::Label { *rhs_block_ptr });
} else if (m_op == AssignmentOp::NullishAssignment) { // ??=
rhs_block_ptr = &generator.make_block();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
lhs_block_ptr = &generator.make_block();
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
end_block_ptr = &generator.make_block();
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
generator.emit<Bytecode::Op::JumpNullish>(
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
lhs,
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
Bytecode::Label { *rhs_block_ptr },
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
Bytecode::Label { *lhs_block_ptr });
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
}
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
if (rhs_block_ptr)
generator.switch_to_basic_block(*rhs_block_ptr);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto rhs = [&]() -> ScopedOperand {
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
if (lhs_expression->is_identifier()) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
return generator.emit_named_evaluation_if_anonymous_function(*m_rhs, generator.intern_identifier(static_cast<Identifier const&>(*lhs_expression).string()));
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
return m_rhs->generate_bytecode(generator).value();
}();
LibJS/Bytecode: Use LHS identifier as function name on logical assign This now creates a function named `x`: x ||= function() { } 9 new passes on test262. :^)
2023-06-26 15:26:46 +02:00
LibJS/Bytecode: Allow assignment expression to write directly to locals
2024-05-14 13:15:14 +02:00
// OPTIMIZATION: If LHS is a local, we can write the result directly into it.
auto dst = [&] {
if (lhs.operand().is_local())
return lhs;
return choose_dst(generator, preferred_dst);
}();
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
switch (m_op) {
case AssignmentOp::AdditionAssignment:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::Add>(dst, lhs, rhs);
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
break;
case AssignmentOp::SubtractionAssignment:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::Sub>(dst, lhs, rhs);
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
break;
case AssignmentOp::MultiplicationAssignment:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::Mul>(dst, lhs, rhs);
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
break;
case AssignmentOp::DivisionAssignment:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::Div>(dst, lhs, rhs);
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
break;
case AssignmentOp::ModuloAssignment:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::Mod>(dst, lhs, rhs);
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
break;
case AssignmentOp::ExponentiationAssignment:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::Exp>(dst, lhs, rhs);
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
break;
case AssignmentOp::BitwiseAndAssignment:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::BitwiseAnd>(dst, lhs, rhs);
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
break;
case AssignmentOp::BitwiseOrAssignment:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::BitwiseOr>(dst, lhs, rhs);
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
break;
case AssignmentOp::BitwiseXorAssignment:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::BitwiseXor>(dst, lhs, rhs);
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
break;
case AssignmentOp::LeftShiftAssignment:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::LeftShift>(dst, lhs, rhs);
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
break;
case AssignmentOp::RightShiftAssignment:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::RightShift>(dst, lhs, rhs);
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
break;
case AssignmentOp::UnsignedRightShiftAssignment:
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::UnsignedRightShift>(dst, lhs, rhs);
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
break;
case AssignmentOp::AndAssignment:
case AssignmentOp::OrAssignment:
case AssignmentOp::NullishAssignment:
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(dst, rhs);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
break;
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
default:
LibJS: Convert unreachable codegen error sites to VERIFY Replace CodeGenerationError returns with VERIFY_NOT_REACHED() or VERIFY() at sites that are provably unreachable: - Non-computed member expression fallbacks in emit_load_from_reference, emit_store_to_reference, and emit_delete_reference (member expression properties are always computed, identifier, or private identifier) - Two non-computed member expression fallbacks in AssignmentExpression - Default case in compound assignment switch (all 15 AssignmentOp values are handled) - BindingPattern Empty/Expression name+alias pair (computed property names always require an alias) - Two assignment+destructuring combinations in for-in/of body evaluation (is_destructuring is only set for VariableDeclaration lhs, which always has VarBinding or LexicalBinding kind, never Assignment)
2026-02-11 22:05:55 +01:00
VERIFY_NOT_REACHED();
LibJS: Add PutById bytecode instruction for object property assignment Note that this is only used for non-computed accesses. Computed access is not yet implemented. :^)
2021-06-04 20:47:07 +02:00
}
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
if (lhs_expression->is_identifier())
generator.emit_set_variable(static_cast<Identifier const&>(*lhs_expression), dst);
LibJS: Don't evaluate computed MemberExpression LHS twice in assignments The following snippet would cause "i" to be incremented twice(!): let a = [] let i = 0 a[++i] += 0 This patch solves the issue by remembering the base object and property name for computed MemberExpression LHS in codegen. We the store the result of the assignment to the same object and property (instead of computing the LHS again). 3 new passes on test262. :^)
2023-10-04 15:22:07 +02:00
else
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
generator.emit_store_to_reference(reference_operands, dst);
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
if (rhs_block_ptr) {
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { *end_block_ptr });
}
if (lhs_block_ptr) {
generator.switch_to_basic_block(*lhs_block_ptr);
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(dst, lhs);
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { *end_block_ptr });
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
}
if (end_block_ptr) {
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
generator.switch_to_basic_block(*end_block_ptr);
}
LibJS: Make ASTNode::generate_bytecode() fallible Instead of crashing on the spot, return a descriptive error that will eventually continue its days as a javascript "InternalError" exception. This should make random crashes with BC less likely.
2022-02-12 19:54:08 +03:30
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return dst;
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
}
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
// 14.13.3 Runtime Semantics: Evaluation, https://tc39.es/ecma262/#sec-labelled-statements-runtime-semantics-evaluation
// LabelledStatement : LabelIdentifier : LabelledItem
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> LabelledStatement::generate_bytecode(Bytecode::Generator& generator, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
// Return ? LabelledEvaluation of this LabelledStatement with argument « ».
return generate_labelled_evaluation(generator, {});
}
// 14.13.4 Runtime Semantics: LabelledEvaluation, https://tc39.es/ecma262/#sec-runtime-semantics-labelledevaluation
// LabelledStatement : LabelIdentifier : LabelledItem
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> LabelledStatement::generate_labelled_evaluation(Bytecode::Generator& generator, Vector<FlyString> const& label_set, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
// Convert the m_labelled_item NNRP to a reference early so we don't have to do it every single time we want to use it.
auto const& labelled_item = *m_labelled_item;
// 1. Let label be the StringValue of LabelIdentifier.
// NOTE: Not necessary, this is m_label.
// 2. Let newLabelSet be the list-concatenation of labelSet and « label ».
// FIXME: Avoid copy here.
auto new_label_set = label_set;
new_label_set.append(m_label);
// 3. Let stmtResult be LabelledEvaluation of LabelledItem with argument newLabelSet.
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
Optional<ScopedOperand> stmt_result;
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
if (is<IterationStatement>(labelled_item)) {
auto const& iteration_statement = static_cast<IterationStatement const&>(labelled_item);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
stmt_result = iteration_statement.generate_labelled_evaluation(generator, new_label_set);
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
} else if (is<SwitchStatement>(labelled_item)) {
auto const& switch_statement = static_cast<SwitchStatement const&>(labelled_item);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
stmt_result = switch_statement.generate_labelled_evaluation(generator, new_label_set);
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
} else if (is<LabelledStatement>(labelled_item)) {
auto const& labelled_statement = static_cast<LabelledStatement const&>(labelled_item);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
stmt_result = labelled_statement.generate_labelled_evaluation(generator, new_label_set);
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
} else {
auto& labelled_break_block = generator.make_block();
// NOTE: We do not need a continuable scope as `continue;` is not allowed outside of iteration statements, throwing a SyntaxError in the parser.
generator.begin_breakable_scope(Bytecode::Label { labelled_break_block }, new_label_set);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
stmt_result = labelled_item.generate_bytecode(generator);
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
generator.end_breakable_scope();
if (!generator.is_current_block_terminated()) {
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { labelled_break_block });
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
}
generator.switch_to_basic_block(labelled_break_block);
}
// 4. If stmtResult.[[Type]] is break and SameValue(stmtResult.[[Target]], label) is true, then
// a. Set stmtResult to NormalCompletion(stmtResult.[[Value]]).
// NOTE: These steps are performed by making labelled break jump straight to the appropriate break block, which preserves the statement result's value in the accumulator.
// 5. Return Completion(stmtResult).
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return stmt_result;
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> WhileStatement::generate_bytecode(Bytecode::Generator& generator, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
return generate_labelled_evaluation(generator, {});
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> WhileStatement::generate_labelled_evaluation(Bytecode::Generator& generator, Vector<FlyString> const& label_set, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS: Add basic support for while loops in the bytecode engine This introduces two new instructions: Jump and JumpIfFalse. Jumps are made to a Bytecode::Label, which is a simple object that represents a location in the bytecode stream. Note that you may not always know the target of a jump when adding the jump instruction itself, but we can just update the instruction later on during codegen once we know where the jump target is. The Bytecode::Interpreter now implements jumping via a jump slot that gets checked after each instruction to see if a jump is pending. If not, we just increment the PC as usual.
2021-06-04 12:07:38 +02:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS: Dead code elimination for always truthy/falsey conditions This improves and expands the ability to do dead code elimination on conditions which are always truthy or falsey. The following cases are now optimized: * `if (true){}` -> Only emit `if` block, ignore `else` * `if (false){}` -> Only emit `else if`/`else` block * `while (false){}` -> Ignore `while` loop entirely * `for (x;false;){}` -> Only emit `x` (if it exists), skip `for` block * Ternary -> Directly return left/right hand side if condition is const
2026-01-25 10:57:43 -08:00
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
auto& test_block = generator.make_block();
LibJS/Bytecode: Don't bother propagating completion values in functions The last completion value in a function is not exposed to the language, since functions always either return something, or undefined. Given this, we can avoid emitting code that propagates the completion value from various statements, as long as we know we're generating code for a context where the completion value is not accessible. In practical terms, this means that function code gets to do less completion shuffling, while global and eval code has to keep doing it.
2024-05-14 10:57:06 +02:00
Optional<ScopedOperand> completion;
if (generator.must_propagate_completion()) {
completion = generator.allocate_register();
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(*completion, generator.add_constant(js_undefined()));
LibJS/Bytecode: Don't bother propagating completion values in functions The last completion value in a function is not exposed to the language, since functions always either return something, or undefined. Given this, we can avoid emitting code that propagates the completion value from various statements, as long as we know we're generating code for a context where the completion value is not accessible. In practical terms, this means that function code gets to do less completion shuffling, while global and eval code has to keep doing it.
2024-05-14 10:57:06 +02:00
}
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { test_block });
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
generator.switch_to_basic_block(test_block);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto test = m_test->generate_bytecode(generator).value();
LibJS: Dead code elimination for always truthy/falsey conditions This improves and expands the ability to do dead code elimination on conditions which are always truthy or falsey. The following cases are now optimized: * `if (true){}` -> Only emit `if` block, ignore `else` * `if (false){}` -> Only emit `else if`/`else` block * `while (false){}` -> Ignore `while` loop entirely * `for (x;false;){}` -> Only emit `x` (if it exists), skip `for` block * Ternary -> Directly return left/right hand side if condition is const
2026-01-25 10:57:43 -08:00
// OPTIMIZATION: If predicate is always false, ignore body and exit early
if (auto constant = generator.try_get_constant(test); constant.has_value() && !constant->to_boolean_slow_case()) {
return completion;
}
// test
// jump if_false (true) end (false) body
// body
// jump always (true) test
// end
auto& body_block = generator.make_block();
auto& end_block = generator.make_block();
LibJS/Bytecode: Do basic compare-and-jump peephole optimization We now fuse sequences like [LessThan, JumpIf] to JumpLessThan. This is only allowed for temporaries (i.e VM registers) with no other references to them.
2024-05-09 15:13:31 +02:00
generator.emit_jump_if(
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
test,
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
Bytecode::Label { body_block },
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
Bytecode::Label { end_block });
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
generator.switch_to_basic_block(body_block);
LibJS: Fix UpdateEmpty completion value semantics for loops/switch/if When a loop or switch body produces an abrupt completion (break or continue) with an empty value, the ES spec requires UpdateEmpty to replace the empty value with the last non-empty completion value V. The bytecode compiler was failing to do this because it only updated the completion register after body codegen, guarded by !is_current_block_terminated(). When break/continue terminated the block, the update was skipped. Fix this with three changes: 1. Introduce a CompletionRegisterScope that tells ScopeNode::generate_bytecode to eagerly emit Mov instructions into the completion register after each value-producing statement. This ensures the register is up to date before any break or continue fires. 2. Give IfStatement its own CompletionRegisterScope (initialized to undefined) during branch evaluation. This models the spec's UpdateEmpty(stmtCompletion, undefined) for if-statements: when break/continue fires inside an if-branch, the scoped jump propagation sees that the if's completion register differs from the loop's and emits a Mov, correctly replacing the eagerly written value with undefined. Without this, code like { 3; if (true) { break; } else { } } would incorrectly carry the value 3 instead of undefined through the break. 3. Capture loop body results and emit a fallback Mov for non-ScopeNode bodies (e.g. bare expression statements like do x=1; while(false)) that don't participate in the eager CompletionRegisterScope update mechanism. For labelled break/continue that cross loop boundaries, the jump codegen now propagates the inner completion register to the target scope's completion register before emitting the jump. Also fix ForStatement to use a proper completion register (previously it returned the body result directly, which was wrong for empty bodies and break-with-no-value cases).
2026-02-10 23:25:24 +01:00
generator.begin_continuable_scope(Bytecode::Label { test_block }, label_set, completion);
generator.begin_breakable_scope(Bytecode::Label { end_block }, label_set, completion);
{
Optional<Bytecode::Generator::CompletionRegisterScope> completion_scope;
if (completion.has_value())
completion_scope.emplace(generator, *completion);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto body = m_body->generate_bytecode(generator);
LibJS: Fix UpdateEmpty completion value semantics for loops/switch/if When a loop or switch body produces an abrupt completion (break or continue) with an empty value, the ES spec requires UpdateEmpty to replace the empty value with the last non-empty completion value V. The bytecode compiler was failing to do this because it only updated the completion register after body codegen, guarded by !is_current_block_terminated(). When break/continue terminated the block, the update was skipped. Fix this with three changes: 1. Introduce a CompletionRegisterScope that tells ScopeNode::generate_bytecode to eagerly emit Mov instructions into the completion register after each value-producing statement. This ensures the register is up to date before any break or continue fires. 2. Give IfStatement its own CompletionRegisterScope (initialized to undefined) during branch evaluation. This models the spec's UpdateEmpty(stmtCompletion, undefined) for if-statements: when break/continue fires inside an if-branch, the scoped jump propagation sees that the if's completion register differs from the loop's and emits a Mov, correctly replacing the eagerly written value with undefined. Without this, code like { 3; if (true) { break; } else { } } would incorrectly carry the value 3 instead of undefined through the break. 3. Capture loop body results and emit a fallback Mov for non-ScopeNode bodies (e.g. bare expression statements like do x=1; while(false)) that don't participate in the eager CompletionRegisterScope update mechanism. For labelled break/continue that cross loop boundaries, the jump codegen now propagates the inner completion register to the target scope's completion register before emitting the jump. Also fix ForStatement to use a proper completion register (previously it returned the body result directly, which was wrong for empty bodies and break-with-no-value cases).
2026-02-10 23:25:24 +01:00
if (!generator.is_current_block_terminated() && completion.has_value() && body.has_value())
generator.emit_mov(*completion, *body);
}
LibJS/Bytecode: Unconditionally end break/continuable scopes Previously we would only end these scopes if the block was not terminated. If the block was generated, we would not end the scope and would generate other bytecode with these scopes still open. These functions do not generate any code, so they can be used even if the current block is terminated. The enter and end scope functions are only used to track where to unwind to when break/continue are used.
2022-03-14 02:13:33 +00:00
generator.end_breakable_scope();
generator.end_continuable_scope();
LibJS: Fix UpdateEmpty completion value semantics for loops/switch/if When a loop or switch body produces an abrupt completion (break or continue) with an empty value, the ES spec requires UpdateEmpty to replace the empty value with the last non-empty completion value V. The bytecode compiler was failing to do this because it only updated the completion register after body codegen, guarded by !is_current_block_terminated(). When break/continue terminated the block, the update was skipped. Fix this with three changes: 1. Introduce a CompletionRegisterScope that tells ScopeNode::generate_bytecode to eagerly emit Mov instructions into the completion register after each value-producing statement. This ensures the register is up to date before any break or continue fires. 2. Give IfStatement its own CompletionRegisterScope (initialized to undefined) during branch evaluation. This models the spec's UpdateEmpty(stmtCompletion, undefined) for if-statements: when break/continue fires inside an if-branch, the scoped jump propagation sees that the if's completion register differs from the loop's and emits a Mov, correctly replacing the eagerly written value with undefined. Without this, code like { 3; if (true) { break; } else { } } would incorrectly carry the value 3 instead of undefined through the break. 3. Capture loop body results and emit a fallback Mov for non-ScopeNode bodies (e.g. bare expression statements like do x=1; while(false)) that don't participate in the eager CompletionRegisterScope update mechanism. For labelled break/continue that cross loop boundaries, the jump codegen now propagates the inner completion register to the target scope's completion register before emitting the jump. Also fix ForStatement to use a proper completion register (previously it returned the body result directly, which was wrong for empty bodies and break-with-no-value cases).
2026-02-10 23:25:24 +01:00
if (!generator.is_current_block_terminated())
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { test_block });
LibJS: Make ASTNode::generate_bytecode() fallible Instead of crashing on the spot, return a descriptive error that will eventually continue its days as a javascript "InternalError" exception. This should make random crashes with BC less likely.
2022-02-12 19:54:08 +03:30
LibJS/Bytecode: Return the proper result for iteration statements
2023-06-25 20:52:35 +01:00
generator.switch_to_basic_block(end_block);
LibJS/Bytecode: Don't bother propagating completion values in functions The last completion value in a function is not exposed to the language, since functions always either return something, or undefined. Given this, we can avoid emitting code that propagates the completion value from various statements, as long as we know we're generating code for a context where the completion value is not accessible. In practical terms, this means that function code gets to do less completion shuffling, while global and eval code has to keep doing it.
2024-05-14 10:57:06 +02:00
return completion;
LibJS: Add basic support for while loops in the bytecode engine This introduces two new instructions: Jump and JumpIfFalse. Jumps are made to a Bytecode::Label, which is a simple object that represents a location in the bytecode stream. Note that you may not always know the target of a jump when adding the jump instruction itself, but we can just update the instruction later on during codegen once we know where the jump target is. The Bytecode::Interpreter now implements jumping via a jump slot that gets checked after each instruction to see if a jump is pending. If not, we just increment the PC as usual.
2021-06-04 12:07:38 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> DoWhileStatement::generate_bytecode(Bytecode::Generator& generator, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
return generate_labelled_evaluation(generator, {});
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> DoWhileStatement::generate_labelled_evaluation(Bytecode::Generator& generator, Vector<FlyString> const& label_set, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS: Generate bytecode for do...while statements :^) This was quite straightforward using the same label/jump machinery that we added for while statements. The main addition here is a new JumpIfTrue bytecode instruction.
2021-06-04 12:20:44 +02:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
// jump always (true) body
// test
// jump if_false (true) end (false) body
// body
// jump always (true) test
// end
auto& body_block = generator.make_block();
LibJS/Bytecode: Emit `do...while` body before test in codegen This makes the code flow naturally and allows jump elision to work.
2024-05-06 13:38:08 +02:00
auto& test_block = generator.make_block();
LibJS/Bytecode: Return the proper result for iteration statements
2023-06-25 20:52:35 +01:00
auto& load_result_and_jump_to_end_block = generator.make_block();
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
auto& end_block = generator.make_block();
LibJS/Bytecode: Don't bother propagating completion values in functions The last completion value in a function is not exposed to the language, since functions always either return something, or undefined. Given this, we can avoid emitting code that propagates the completion value from various statements, as long as we know we're generating code for a context where the completion value is not accessible. In practical terms, this means that function code gets to do less completion shuffling, while global and eval code has to keep doing it.
2024-05-14 10:57:06 +02:00
Optional<ScopedOperand> completion;
if (generator.must_propagate_completion()) {
completion = generator.allocate_register();
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(*completion, generator.add_constant(js_undefined()));
LibJS/Bytecode: Don't bother propagating completion values in functions The last completion value in a function is not exposed to the language, since functions always either return something, or undefined. Given this, we can avoid emitting code that propagates the completion value from various statements, as long as we know we're generating code for a context where the completion value is not accessible. In practical terms, this means that function code gets to do less completion shuffling, while global and eval code has to keep doing it.
2024-05-14 10:57:06 +02:00
}
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
// jump to the body block
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { body_block });
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
generator.switch_to_basic_block(test_block);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto test = m_test->generate_bytecode(generator).value();
LibJS/Bytecode: Do basic compare-and-jump peephole optimization We now fuse sequences like [LessThan, JumpIf] to JumpLessThan. This is only allowed for temporaries (i.e VM registers) with no other references to them.
2024-05-09 15:13:31 +02:00
generator.emit_jump_if(
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
test,
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
Bytecode::Label { body_block },
LibJS/Bytecode: Return the proper result for iteration statements
2023-06-25 20:52:35 +01:00
Bytecode::Label { load_result_and_jump_to_end_block });
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
generator.switch_to_basic_block(body_block);
LibJS: Fix UpdateEmpty completion value semantics for loops/switch/if When a loop or switch body produces an abrupt completion (break or continue) with an empty value, the ES spec requires UpdateEmpty to replace the empty value with the last non-empty completion value V. The bytecode compiler was failing to do this because it only updated the completion register after body codegen, guarded by !is_current_block_terminated(). When break/continue terminated the block, the update was skipped. Fix this with three changes: 1. Introduce a CompletionRegisterScope that tells ScopeNode::generate_bytecode to eagerly emit Mov instructions into the completion register after each value-producing statement. This ensures the register is up to date before any break or continue fires. 2. Give IfStatement its own CompletionRegisterScope (initialized to undefined) during branch evaluation. This models the spec's UpdateEmpty(stmtCompletion, undefined) for if-statements: when break/continue fires inside an if-branch, the scoped jump propagation sees that the if's completion register differs from the loop's and emits a Mov, correctly replacing the eagerly written value with undefined. Without this, code like { 3; if (true) { break; } else { } } would incorrectly carry the value 3 instead of undefined through the break. 3. Capture loop body results and emit a fallback Mov for non-ScopeNode bodies (e.g. bare expression statements like do x=1; while(false)) that don't participate in the eager CompletionRegisterScope update mechanism. For labelled break/continue that cross loop boundaries, the jump codegen now propagates the inner completion register to the target scope's completion register before emitting the jump. Also fix ForStatement to use a proper completion register (previously it returned the body result directly, which was wrong for empty bodies and break-with-no-value cases).
2026-02-10 23:25:24 +01:00
generator.begin_continuable_scope(Bytecode::Label { test_block }, label_set, completion);
generator.begin_breakable_scope(Bytecode::Label { end_block }, label_set, completion);
{
Optional<Bytecode::Generator::CompletionRegisterScope> completion_scope;
if (completion.has_value())
completion_scope.emplace(generator, *completion);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto body = m_body->generate_bytecode(generator);
LibJS: Fix UpdateEmpty completion value semantics for loops/switch/if When a loop or switch body produces an abrupt completion (break or continue) with an empty value, the ES spec requires UpdateEmpty to replace the empty value with the last non-empty completion value V. The bytecode compiler was failing to do this because it only updated the completion register after body codegen, guarded by !is_current_block_terminated(). When break/continue terminated the block, the update was skipped. Fix this with three changes: 1. Introduce a CompletionRegisterScope that tells ScopeNode::generate_bytecode to eagerly emit Mov instructions into the completion register after each value-producing statement. This ensures the register is up to date before any break or continue fires. 2. Give IfStatement its own CompletionRegisterScope (initialized to undefined) during branch evaluation. This models the spec's UpdateEmpty(stmtCompletion, undefined) for if-statements: when break/continue fires inside an if-branch, the scoped jump propagation sees that the if's completion register differs from the loop's and emits a Mov, correctly replacing the eagerly written value with undefined. Without this, code like { 3; if (true) { break; } else { } } would incorrectly carry the value 3 instead of undefined through the break. 3. Capture loop body results and emit a fallback Mov for non-ScopeNode bodies (e.g. bare expression statements like do x=1; while(false)) that don't participate in the eager CompletionRegisterScope update mechanism. For labelled break/continue that cross loop boundaries, the jump codegen now propagates the inner completion register to the target scope's completion register before emitting the jump. Also fix ForStatement to use a proper completion register (previously it returned the body result directly, which was wrong for empty bodies and break-with-no-value cases).
2026-02-10 23:25:24 +01:00
if (!generator.is_current_block_terminated() && completion.has_value() && body.has_value())
generator.emit_mov(*completion, *body);
}
LibJS/Bytecode: Unconditionally end break/continuable scopes Previously we would only end these scopes if the block was not terminated. If the block was generated, we would not end the scope and would generate other bytecode with these scopes still open. These functions do not generate any code, so they can be used even if the current block is terminated. The enter and end scope functions are only used to track where to unwind to when break/continue are used.
2022-03-14 02:13:33 +00:00
generator.end_breakable_scope();
generator.end_continuable_scope();
LibJS: Fix UpdateEmpty completion value semantics for loops/switch/if When a loop or switch body produces an abrupt completion (break or continue) with an empty value, the ES spec requires UpdateEmpty to replace the empty value with the last non-empty completion value V. The bytecode compiler was failing to do this because it only updated the completion register after body codegen, guarded by !is_current_block_terminated(). When break/continue terminated the block, the update was skipped. Fix this with three changes: 1. Introduce a CompletionRegisterScope that tells ScopeNode::generate_bytecode to eagerly emit Mov instructions into the completion register after each value-producing statement. This ensures the register is up to date before any break or continue fires. 2. Give IfStatement its own CompletionRegisterScope (initialized to undefined) during branch evaluation. This models the spec's UpdateEmpty(stmtCompletion, undefined) for if-statements: when break/continue fires inside an if-branch, the scoped jump propagation sees that the if's completion register differs from the loop's and emits a Mov, correctly replacing the eagerly written value with undefined. Without this, code like { 3; if (true) { break; } else { } } would incorrectly carry the value 3 instead of undefined through the break. 3. Capture loop body results and emit a fallback Mov for non-ScopeNode bodies (e.g. bare expression statements like do x=1; while(false)) that don't participate in the eager CompletionRegisterScope update mechanism. For labelled break/continue that cross loop boundaries, the jump codegen now propagates the inner completion register to the target scope's completion register before emitting the jump. Also fix ForStatement to use a proper completion register (previously it returned the body result directly, which was wrong for empty bodies and break-with-no-value cases).
2026-02-10 23:25:24 +01:00
if (!generator.is_current_block_terminated())
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { test_block });
LibJS: Make ASTNode::generate_bytecode() fallible Instead of crashing on the spot, return a descriptive error that will eventually continue its days as a javascript "InternalError" exception. This should make random crashes with BC less likely.
2022-02-12 19:54:08 +03:30
LibJS/Bytecode: Return the proper result for iteration statements
2023-06-25 20:52:35 +01:00
generator.switch_to_basic_block(load_result_and_jump_to_end_block);
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { end_block });
generator.switch_to_basic_block(end_block);
LibJS/Bytecode: Don't bother propagating completion values in functions The last completion value in a function is not exposed to the language, since functions always either return something, or undefined. Given this, we can avoid emitting code that propagates the completion value from various statements, as long as we know we're generating code for a context where the completion value is not accessible. In practical terms, this means that function code gets to do less completion shuffling, while global and eval code has to keep doing it.
2024-05-14 10:57:06 +02:00
return completion;
LibJS: Generate bytecode for do...while statements :^) This was quite straightforward using the same label/jump machinery that we added for while statements. The main addition here is a new JumpIfTrue bytecode instruction.
2021-06-04 12:20:44 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> ForStatement::generate_bytecode(Bytecode::Generator& generator, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
return generate_labelled_evaluation(generator, {});
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> ForStatement::generate_labelled_evaluation(Bytecode::Generator& generator, Vector<FlyString> const& label_set, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS: Add for loop bytecode generation
2021-06-08 10:54:40 +01:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
// init
// jump always (true) test
// test
// jump if_true (true) body (false) end
// body
// jump always (true) update
// update
// jump always (true) test
// end
// If 'test' is missing, fuse the 'test' and 'body' basic blocks
// If 'update' is missing, fuse the 'body' and 'update' basic blocks
Bytecode::BasicBlock* test_block_ptr { nullptr };
Bytecode::BasicBlock* body_block_ptr { nullptr };
Bytecode::BasicBlock* update_block_ptr { nullptr };
LibJS/Bytecode: Setup declarative environment for lexical for statements
2022-03-14 02:39:24 +00:00
bool has_lexical_environment = false;
LibJS: Implement CreatePerIterationEnvironment for 'for' statements Implement for CreatePerIterationEnvironment for 'for' loops per the Ecma Standard. This ensures each iteration of a 'for' loop has its own lexical environment so that variables declared in the loop are scoped to the current iteration.
2024-07-16 16:56:02 -04:00
Vector<IdentifierTableIndex> per_iteration_bindings;
LibJS/Bytecode: Setup declarative environment for lexical for statements
2022-03-14 02:39:24 +00:00
if (m_init) {
if (m_init->is_variable_declaration()) {
AK+Everywhere: Rename `verify_cast` to `as` Follow-up to fc20e61e7249006247b43f84a3189d5a37fa103e.
2025-01-21 09:12:05 -05:00
auto& variable_declaration = as<VariableDeclaration>(*m_init);
LibJS/Bytecode: Setup declarative environment for lexical for statements
2022-03-14 02:39:24 +00:00
LibJS/Bytecode: Skip CreateVariable for locals in "for" loop head CreateVariable is not needed for locals because they are not stored in environment and created binding will not be used. Also if all variables in loop initialization sections are local then CreateLexicalEnvironment and LeaveLexicalEnvironment can also be ommitted.
2023-07-13 21:30:36 +02:00
auto has_non_local_variables = false;
MUST(variable_declaration.for_each_bound_identifier([&](auto const& identifier) {
if (!identifier.is_local())
has_non_local_variables = true;
}));
if (variable_declaration.is_lexical_declaration() && has_non_local_variables) {
LibJS/Bytecode: Setup declarative environment for lexical for statements
2022-03-14 02:39:24 +00:00
has_lexical_environment = true;
LibJS: Implement CreatePerIterationEnvironment for 'for' statements Implement for CreatePerIterationEnvironment for 'for' loops per the Ecma Standard. This ensures each iteration of a 'for' loop has its own lexical environment so that variables declared in the loop are scoped to the current iteration.
2024-07-16 16:56:02 -04:00
// Setup variable scope for bound identifiers
LibJS/Bytecode: Leave BlockDeclarationInstantiation in C++ Instead of implementing this AO in bytecode, we now have an instruction for it that simply invokes the C++ implementation. This allows us to simplify Bytecode::Generator quite a bit by removing all the variable scope tracking.
2023-06-16 16:34:47 +02:00
generator.begin_variable_scope();
LibJS/Bytecode: Setup declarative environment for lexical for statements
2022-03-14 02:39:24 +00:00
bool is_const = variable_declaration.is_constant_declaration();
LibJS: Don't discard ThrowCompletionOr<void> from declaration iteration
2023-02-27 22:13:37 +00:00
// NOTE: Nothing in the callback throws an exception.
LibJS/Bytecode: Skip CreateVariable for locals in "for" loop head CreateVariable is not needed for locals because they are not stored in environment and created binding will not be used. Also if all variables in loop initialization sections are local then CreateLexicalEnvironment and LeaveLexicalEnvironment can also be ommitted.
2023-07-13 21:30:36 +02:00
MUST(variable_declaration.for_each_bound_identifier([&](auto const& identifier) {
if (identifier.is_local())
return;
auto index = generator.intern_identifier(identifier.string());
LibJS: Generate C++ bytecode instruction classes from a definition file This commit adds a new Bytecode.def file that describes all the LibJS bytecode instructions. From this, we are able to generate the full declarations for all C++ bytecode instruction classes, as well as their serialization code. Note that some of the bytecode compiler was updated since instructions no longer have default constructor arguments. The big immediate benefit here is that we lose a couple thousand lines of hand-written C++ code. Going forward, this also allows us to do more tooling for the bytecode VM, now that we have an authoritative description of its instructions. Key things to know about: - Instructions can inherit from one another. At the moment, everything simply inherits from the base "Instruction". - @terminator means the instruction terminates a basic block. - @nothrow means the instruction cannot throw. This affects how the interpreter interacts with it. - Variable-length instructions are automatically supported. Just put an array of something as the last field of the instruction. - The m_length field is magical. If present, it will be populated with the full length of the instruction. This is used for variable-length instructions.
2025-11-20 22:14:50 +01:00
generator.emit<Bytecode::Op::CreateVariable>(index, Bytecode::Op::EnvironmentMode::Lexical, is_const, false, false);
LibJS: Implement CreatePerIterationEnvironment for 'for' statements Implement for CreatePerIterationEnvironment for 'for' loops per the Ecma Standard. This ensures each iteration of a 'for' loop has its own lexical environment so that variables declared in the loop are scoped to the current iteration.
2024-07-16 16:56:02 -04:00
if (!is_const) {
per_iteration_bindings.append(index);
}
LibJS: Don't discard ThrowCompletionOr<void> from declaration iteration
2023-02-27 22:13:37 +00:00
}));
LibJS/Bytecode: Setup declarative environment for lexical for statements
2022-03-14 02:39:24 +00:00
}
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
(void)m_init->generate_bytecode(generator);
LibJS/Bytecode: Setup declarative environment for lexical for statements
2022-03-14 02:39:24 +00:00
}
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
LibJS: Implement CreatePerIterationEnvironment for 'for' statements Implement for CreatePerIterationEnvironment for 'for' loops per the Ecma Standard. This ensures each iteration of a 'for' loop has its own lexical environment so that variables declared in the loop are scoped to the current iteration.
2024-07-16 16:56:02 -04:00
// CreatePerIterationEnvironment (https://tc39.es/ecma262/multipage/ecmascript-language-statements-and-declarations.html#sec-createperiterationenvironment)
auto generate_per_iteration_bindings = [&per_iteration_bindings = static_cast<Vector<IdentifierTableIndex> const&>(per_iteration_bindings),
&generator]() {
if (per_iteration_bindings.is_empty()) {
return;
}
// Copy all the last values into registers for use in step 1.e.iii
// Register copies of bindings are required since the changing of the
// running execution context in the final step requires leaving the
// current variable scope before creating "thisIterationEnv"
Vector<ScopedOperand> registers;
for (auto const& binding : per_iteration_bindings) {
auto reg = generator.allocate_register();
generator.emit<Bytecode::Op::GetBinding>(reg, binding);
registers.append(reg);
}
generator.end_variable_scope();
generator.begin_variable_scope();
for (size_t i = 0; i < per_iteration_bindings.size(); ++i) {
LibJS: Generate C++ bytecode instruction classes from a definition file This commit adds a new Bytecode.def file that describes all the LibJS bytecode instructions. From this, we are able to generate the full declarations for all C++ bytecode instruction classes, as well as their serialization code. Note that some of the bytecode compiler was updated since instructions no longer have default constructor arguments. The big immediate benefit here is that we lose a couple thousand lines of hand-written C++ code. Going forward, this also allows us to do more tooling for the bytecode VM, now that we have an authoritative description of its instructions. Key things to know about: - Instructions can inherit from one another. At the moment, everything simply inherits from the base "Instruction". - @terminator means the instruction terminates a basic block. - @nothrow means the instruction cannot throw. This affects how the interpreter interacts with it. - Variable-length instructions are automatically supported. Just put an array of something as the last field of the instruction. - The m_length field is magical. If present, it will be populated with the full length of the instruction. This is used for variable-length instructions.
2025-11-20 22:14:50 +01:00
generator.emit<Bytecode::Op::CreateVariable>(per_iteration_bindings[i], Bytecode::Op::EnvironmentMode::Lexical, false, false, false);
LibJS: Implement CreatePerIterationEnvironment for 'for' statements Implement for CreatePerIterationEnvironment for 'for' loops per the Ecma Standard. This ensures each iteration of a 'for' loop has its own lexical environment so that variables declared in the loop are scoped to the current iteration.
2024-07-16 16:56:02 -04:00
generator.emit<Bytecode::Op::InitializeLexicalBinding>(per_iteration_bindings[i], registers[i]);
}
};
LibJS: Fix crash in bytecode generator on https://twinings.co.uk/ If the current block has already been terminated, we should just skip creating a per-iteration environment.
2024-07-24 10:35:39 +02:00
if (m_init) {
// CreatePerIterationEnvironment where lastIterationEnv is the variable
// scope created above for bound identifiers
generate_per_iteration_bindings();
}
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
body_block_ptr = &generator.make_block();
if (m_update)
update_block_ptr = &generator.make_block();
else
update_block_ptr = body_block_ptr;
LibJS/Bytecode: Emit `for` condition check before update statement This allows jump elision to eliminate an unnecessary jump since things now get laid out naturally in memory (normal execution order).
2024-05-06 09:34:42 +02:00
if (m_test)
test_block_ptr = &generator.make_block();
else
test_block_ptr = body_block_ptr;
LibJS/Bytecode: Put end block last in `for` statement codegen
2024-05-06 10:10:38 +02:00
auto& end_block = generator.make_block();
LibJS: Fix UpdateEmpty completion value semantics for loops/switch/if When a loop or switch body produces an abrupt completion (break or continue) with an empty value, the ES spec requires UpdateEmpty to replace the empty value with the last non-empty completion value V. The bytecode compiler was failing to do this because it only updated the completion register after body codegen, guarded by !is_current_block_terminated(). When break/continue terminated the block, the update was skipped. Fix this with three changes: 1. Introduce a CompletionRegisterScope that tells ScopeNode::generate_bytecode to eagerly emit Mov instructions into the completion register after each value-producing statement. This ensures the register is up to date before any break or continue fires. 2. Give IfStatement its own CompletionRegisterScope (initialized to undefined) during branch evaluation. This models the spec's UpdateEmpty(stmtCompletion, undefined) for if-statements: when break/continue fires inside an if-branch, the scoped jump propagation sees that the if's completion register differs from the loop's and emits a Mov, correctly replacing the eagerly written value with undefined. Without this, code like { 3; if (true) { break; } else { } } would incorrectly carry the value 3 instead of undefined through the break. 3. Capture loop body results and emit a fallback Mov for non-ScopeNode bodies (e.g. bare expression statements like do x=1; while(false)) that don't participate in the eager CompletionRegisterScope update mechanism. For labelled break/continue that cross loop boundaries, the jump codegen now propagates the inner completion register to the target scope's completion register before emitting the jump. Also fix ForStatement to use a proper completion register (previously it returned the body result directly, which was wrong for empty bodies and break-with-no-value cases).
2026-02-10 23:25:24 +01:00
Optional<ScopedOperand> completion;
if (generator.must_propagate_completion()) {
completion = generator.allocate_register();
generator.emit_mov(*completion, generator.add_constant(js_undefined()));
}
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { *test_block_ptr });
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
LibJS: Add for loop bytecode generation
2021-06-08 10:54:40 +01:00
if (m_test) {
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
generator.switch_to_basic_block(*test_block_ptr);
LibJS/Bytecode: Return the proper result for iteration statements
2023-06-25 20:52:35 +01:00
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto test = m_test->generate_bytecode(generator).value();
LibJS: Dead code elimination for always truthy/falsey conditions This improves and expands the ability to do dead code elimination on conditions which are always truthy or falsey. The following cases are now optimized: * `if (true){}` -> Only emit `if` block, ignore `else` * `if (false){}` -> Only emit `else if`/`else` block * `while (false){}` -> Ignore `while` loop entirely * `for (x;false;){}` -> Only emit `x` (if it exists), skip `for` block * Ternary -> Directly return left/right hand side if condition is const
2026-01-25 10:57:43 -08:00
// OPTIMIZATION: test value is always falsey, skip body entirely
if (auto constant = generator.try_get_constant(test); constant.has_value() && !constant->to_boolean_slow_case()) {
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { end_block });
generator.switch_to_basic_block(end_block);
LibJS: Fix UpdateEmpty completion value semantics for loops/switch/if When a loop or switch body produces an abrupt completion (break or continue) with an empty value, the ES spec requires UpdateEmpty to replace the empty value with the last non-empty completion value V. The bytecode compiler was failing to do this because it only updated the completion register after body codegen, guarded by !is_current_block_terminated(). When break/continue terminated the block, the update was skipped. Fix this with three changes: 1. Introduce a CompletionRegisterScope that tells ScopeNode::generate_bytecode to eagerly emit Mov instructions into the completion register after each value-producing statement. This ensures the register is up to date before any break or continue fires. 2. Give IfStatement its own CompletionRegisterScope (initialized to undefined) during branch evaluation. This models the spec's UpdateEmpty(stmtCompletion, undefined) for if-statements: when break/continue fires inside an if-branch, the scoped jump propagation sees that the if's completion register differs from the loop's and emits a Mov, correctly replacing the eagerly written value with undefined. Without this, code like { 3; if (true) { break; } else { } } would incorrectly carry the value 3 instead of undefined through the break. 3. Capture loop body results and emit a fallback Mov for non-ScopeNode bodies (e.g. bare expression statements like do x=1; while(false)) that don't participate in the eager CompletionRegisterScope update mechanism. For labelled break/continue that cross loop boundaries, the jump codegen now propagates the inner completion register to the target scope's completion register before emitting the jump. Also fix ForStatement to use a proper completion register (previously it returned the body result directly, which was wrong for empty bodies and break-with-no-value cases).
2026-02-10 23:25:24 +01:00
if (has_lexical_environment)
generator.end_variable_scope();
return completion;
LibJS: Dead code elimination for always truthy/falsey conditions This improves and expands the ability to do dead code elimination on conditions which are always truthy or falsey. The following cases are now optimized: * `if (true){}` -> Only emit `if` block, ignore `else` * `if (false){}` -> Only emit `else if`/`else` block * `while (false){}` -> Ignore `while` loop entirely * `for (x;false;){}` -> Only emit `x` (if it exists), skip `for` block * Ternary -> Directly return left/right hand side if condition is const
2026-01-25 10:57:43 -08:00
}
LibJS/Bytecode: Do basic compare-and-jump peephole optimization We now fuse sequences like [LessThan, JumpIf] to JumpLessThan. This is only allowed for temporaries (i.e VM registers) with no other references to them.
2024-05-09 15:13:31 +02:00
generator.emit_jump_if(test, Bytecode::Label { *body_block_ptr }, Bytecode::Label { end_block });
LibJS: Add for loop bytecode generation
2021-06-08 10:54:40 +01:00
}
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
LibJS/Bytecode: Fix multiple wrong jumps in ForStatement codegen
2023-06-15 19:13:00 +02:00
if (m_update) {
generator.switch_to_basic_block(*update_block_ptr);
LibJS/Bytecode: Return the proper result for iteration statements
2023-06-25 20:52:35 +01:00
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
(void)m_update->generate_bytecode(generator);
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { *test_block_ptr });
LibJS/Bytecode: Fix multiple wrong jumps in ForStatement codegen
2023-06-15 19:13:00 +02:00
}
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
generator.switch_to_basic_block(*body_block_ptr);
LibJS: Fix UpdateEmpty completion value semantics for loops/switch/if When a loop or switch body produces an abrupt completion (break or continue) with an empty value, the ES spec requires UpdateEmpty to replace the empty value with the last non-empty completion value V. The bytecode compiler was failing to do this because it only updated the completion register after body codegen, guarded by !is_current_block_terminated(). When break/continue terminated the block, the update was skipped. Fix this with three changes: 1. Introduce a CompletionRegisterScope that tells ScopeNode::generate_bytecode to eagerly emit Mov instructions into the completion register after each value-producing statement. This ensures the register is up to date before any break or continue fires. 2. Give IfStatement its own CompletionRegisterScope (initialized to undefined) during branch evaluation. This models the spec's UpdateEmpty(stmtCompletion, undefined) for if-statements: when break/continue fires inside an if-branch, the scoped jump propagation sees that the if's completion register differs from the loop's and emits a Mov, correctly replacing the eagerly written value with undefined. Without this, code like { 3; if (true) { break; } else { } } would incorrectly carry the value 3 instead of undefined through the break. 3. Capture loop body results and emit a fallback Mov for non-ScopeNode bodies (e.g. bare expression statements like do x=1; while(false)) that don't participate in the eager CompletionRegisterScope update mechanism. For labelled break/continue that cross loop boundaries, the jump codegen now propagates the inner completion register to the target scope's completion register before emitting the jump. Also fix ForStatement to use a proper completion register (previously it returned the body result directly, which was wrong for empty bodies and break-with-no-value cases).
2026-02-10 23:25:24 +01:00
generator.begin_continuable_scope(Bytecode::Label { m_update ? *update_block_ptr : *test_block_ptr }, label_set, completion);
generator.begin_breakable_scope(Bytecode::Label { end_block }, label_set, completion);
{
Optional<Bytecode::Generator::CompletionRegisterScope> completion_scope;
if (completion.has_value())
completion_scope.emplace(generator, *completion);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto body = m_body->generate_bytecode(generator);
LibJS: Fix UpdateEmpty completion value semantics for loops/switch/if When a loop or switch body produces an abrupt completion (break or continue) with an empty value, the ES spec requires UpdateEmpty to replace the empty value with the last non-empty completion value V. The bytecode compiler was failing to do this because it only updated the completion register after body codegen, guarded by !is_current_block_terminated(). When break/continue terminated the block, the update was skipped. Fix this with three changes: 1. Introduce a CompletionRegisterScope that tells ScopeNode::generate_bytecode to eagerly emit Mov instructions into the completion register after each value-producing statement. This ensures the register is up to date before any break or continue fires. 2. Give IfStatement its own CompletionRegisterScope (initialized to undefined) during branch evaluation. This models the spec's UpdateEmpty(stmtCompletion, undefined) for if-statements: when break/continue fires inside an if-branch, the scoped jump propagation sees that the if's completion register differs from the loop's and emits a Mov, correctly replacing the eagerly written value with undefined. Without this, code like { 3; if (true) { break; } else { } } would incorrectly carry the value 3 instead of undefined through the break. 3. Capture loop body results and emit a fallback Mov for non-ScopeNode bodies (e.g. bare expression statements like do x=1; while(false)) that don't participate in the eager CompletionRegisterScope update mechanism. For labelled break/continue that cross loop boundaries, the jump codegen now propagates the inner completion register to the target scope's completion register before emitting the jump. Also fix ForStatement to use a proper completion register (previously it returned the body result directly, which was wrong for empty bodies and break-with-no-value cases).
2026-02-10 23:25:24 +01:00
if (!generator.is_current_block_terminated() && completion.has_value() && body.has_value())
generator.emit_mov(*completion, *body);
}
LibJS/Bytecode: Don't begin breakable scope before variable scope in for This is no longer required, since the variable scope is ended after switching to the end block, which means that LeaveLexicalEnvironment will always be generated instead of depending on the unwind mechanism to handle it for us.
2022-07-17 19:22:18 +01:00
generator.end_breakable_scope();
LibJS: Add for loop bytecode generation
2021-06-08 10:54:40 +01:00
generator.end_continuable_scope();
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
LibJS: Don't generate code after we've encountered a terminating op
2021-06-09 19:57:18 +02:00
if (!generator.is_current_block_terminated()) {
LibJS: Fix crash in bytecode generator on https://twinings.co.uk/ If the current block has already been terminated, we should just skip creating a per-iteration environment.
2024-07-24 10:35:39 +02:00
// CreatePerIterationEnvironment where lastIterationEnv is the environment
// created by the previous CreatePerIterationEnvironment setup
generate_per_iteration_bindings();
LibJS: Don't generate code after we've encountered a terminating op
2021-06-09 19:57:18 +02:00
if (m_update) {
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { *update_block_ptr });
LibJS/Bytecode: Fix multiple wrong jumps in ForStatement codegen
2023-06-15 19:13:00 +02:00
} else {
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { *test_block_ptr });
LibJS: Don't generate code after we've encountered a terminating op
2021-06-09 19:57:18 +02:00
}
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
}
LibJS: Make ASTNode::generate_bytecode() fallible Instead of crashing on the spot, return a descriptive error that will eventually continue its days as a javascript "InternalError" exception. This should make random crashes with BC less likely.
2022-02-12 19:54:08 +03:30
LibJS/Bytecode: End the for variable scope at the start of its end block If the for loop's body is not block terminated, we will generate a Jump to the end block which will block terminate the body. Then, we ended the lexical variable scope if needed. However, since the body is now block terminated, the "LeaveLexicalEnvironment" instruction that is generated by end_variable_scope is now dropped on the floor. This fixes this by moving it to the beginning of the end block.
2022-06-30 15:55:57 +01:00
generator.switch_to_basic_block(end_block);
LibJS: Implement CreatePerIterationEnvironment for 'for' statements Implement for CreatePerIterationEnvironment for 'for' loops per the Ecma Standard. This ensures each iteration of a 'for' loop has its own lexical environment so that variables declared in the loop are scoped to the current iteration.
2024-07-16 16:56:02 -04:00
// Leave the environment setup by CreatePerIterationEnvironment or if there
// are no perIterationBindings the variable scope created for bound
// identifiers
LibJS/Bytecode: End for's variable scope after update block generation The update block can generate bytecode that refers to the lexical environment, so we have to end the scope after it has been generated. Previously the Jump to the update block would terminate the block, causing us to leave the lexical environment just before jumping to the update block.
2022-03-15 01:44:32 +00:00
if (has_lexical_environment)
generator.end_variable_scope();
LibJS: Fix UpdateEmpty completion value semantics for loops/switch/if When a loop or switch body produces an abrupt completion (break or continue) with an empty value, the ES spec requires UpdateEmpty to replace the empty value with the last non-empty completion value V. The bytecode compiler was failing to do this because it only updated the completion register after body codegen, guarded by !is_current_block_terminated(). When break/continue terminated the block, the update was skipped. Fix this with three changes: 1. Introduce a CompletionRegisterScope that tells ScopeNode::generate_bytecode to eagerly emit Mov instructions into the completion register after each value-producing statement. This ensures the register is up to date before any break or continue fires. 2. Give IfStatement its own CompletionRegisterScope (initialized to undefined) during branch evaluation. This models the spec's UpdateEmpty(stmtCompletion, undefined) for if-statements: when break/continue fires inside an if-branch, the scoped jump propagation sees that the if's completion register differs from the loop's and emits a Mov, correctly replacing the eagerly written value with undefined. Without this, code like { 3; if (true) { break; } else { } } would incorrectly carry the value 3 instead of undefined through the break. 3. Capture loop body results and emit a fallback Mov for non-ScopeNode bodies (e.g. bare expression statements like do x=1; while(false)) that don't participate in the eager CompletionRegisterScope update mechanism. For labelled break/continue that cross loop boundaries, the jump codegen now propagates the inner completion register to the target scope's completion register before emitting the jump. Also fix ForStatement to use a proper completion register (previously it returned the body result directly, which was wrong for empty bodies and break-with-no-value cases).
2026-02-10 23:25:24 +01:00
return completion;
LibJS: Add for loop bytecode generation
2021-06-08 10:54:40 +01:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> ObjectExpression::generate_bytecode(Bytecode::Generator& generator, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS: Add a NewObject bytecode instruction for ObjectExpression :^)
2021-06-04 20:30:23 +02:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS: Add a NewObject bytecode instruction for ObjectExpression :^)
2021-06-04 20:30:23 +02:00
LibJS: Store NewObject result directly in preferred dst if possible This avoids a Mov after every object literal.
2025-03-27 15:49:49 +00:00
auto object = choose_dst(generator, preferred_dst);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
LibJS: Fix object literal shape caching for numeric string keys Numeric string keys like "0" are converted to numeric property keys and stored in indexed storage rather than shape-based storage. The shape caching optimization introduced in 505fe0a9775 didn't account for this, causing properties with numeric keys to be lost on subsequent calls. The fix excludes object literals with numeric string keys from the shape caching fast path by checking if any key would become a numeric property index.
2026-01-20 15:11:43 +01:00
// Determine if this is a simple object literal (all KeyValue with StringLiteral keys
// that are not numeric indices). Simple literals can benefit from shape caching with
// direct property offset writes. Numeric string keys like "0" are stored in indexed
// storage rather than shape-based storage, so they can't use the fast path.
LibJS: Add shape caching for object literal instantiation When a function creates object literals with simple property names, we now cache the resulting shape after the first instantiation. On subsequent calls, we create the object with the cached shape directly and write property values at their known offsets. This avoids repeated shape transitions and property offset lookups for a common JavaScript pattern. The optimization uses two new bytecode instructions: - CacheObjectShape: Captures the final shape after object construction - InitObjectLiteralProperty: Writes properties using cached offsets Only "simple" object literals are optimized (string literal keys with simple value expressions). Complex cases like computed properties, getters/setters, and spread elements use the existing slow path. 3.4x speedup on a microbenchmark that repeatedly instantiates an object literal with 26 properties. Small progressions on various benchmarks.
2026-01-09 18:55:00 +01:00
bool is_simple = !m_properties.is_empty();
for (auto& property : m_properties) {
if (property->type() != ObjectProperty::Type::KeyValue || !is<StringLiteral>(property->key())) {
is_simple = false;
break;
}
LibJS: Fix object literal shape caching for numeric string keys Numeric string keys like "0" are converted to numeric property keys and stored in indexed storage rather than shape-based storage. The shape caching optimization introduced in 505fe0a9775 didn't account for this, causing properties with numeric keys to be lost on subsequent calls. The fix excludes object literals with numeric string keys from the shape caching fast path by checking if any key would become a numeric property index.
2026-01-20 15:11:43 +01:00
// Check if the key is a numeric index (would be stored in indexed storage)
auto const& key = static_cast<StringLiteral const&>(property->key()).value();
if (!key.is_empty() && !(key.code_unit_at(0) == '0' && key.length_in_code_units() > 1)) {
auto property_index = key.to_number<u32>(TrimWhitespace::No);
if (property_index.has_value() && property_index.value() < NumericLimits<u32>::max()) {
is_simple = false;
break;
}
}
LibJS: Add shape caching for object literal instantiation When a function creates object literals with simple property names, we now cache the resulting shape after the first instantiation. On subsequent calls, we create the object with the cached shape directly and write property values at their known offsets. This avoids repeated shape transitions and property offset lookups for a common JavaScript pattern. The optimization uses two new bytecode instructions: - CacheObjectShape: Captures the final shape after object construction - InitObjectLiteralProperty: Writes properties using cached offsets Only "simple" object literals are optimized (string literal keys with simple value expressions). Complex cases like computed properties, getters/setters, and spread elements use the existing slow path. 3.4x speedup on a microbenchmark that repeatedly instantiates an object literal with 26 properties. Small progressions on various benchmarks.
2026-01-09 18:55:00 +01:00
}
Optional<u32> shape_cache_index;
if (is_simple)
shape_cache_index = generator.next_object_shape_cache();
generator.emit<Bytecode::Op::NewObject>(object, shape_cache_index.value_or(NumericLimits<u32>::max()));
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
if (m_properties.is_empty())
return object;
LibJS: Add bytecode generation for simple ObjectExpressions Bytecode is now generated for object literals which only contain simple key-value pairs (i.e. no spread, getters or setters)
2021-06-11 19:40:48 +03:00
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.push_home_object(object);
LibJS/Bytecode: Set "home object" of functions within object expression We manage this by having a stack of home objects in Generator, and then adding an optional home object parameter to the NewFunction instruction.
2023-06-16 10:25:05 +02:00
LibJS: Add shape caching for object literal instantiation When a function creates object literals with simple property names, we now cache the resulting shape after the first instantiation. On subsequent calls, we create the object with the cached shape directly and write property values at their known offsets. This avoids repeated shape transitions and property offset lookups for a common JavaScript pattern. The optimization uses two new bytecode instructions: - CacheObjectShape: Captures the final shape after object construction - InitObjectLiteralProperty: Writes properties using cached offsets Only "simple" object literals are optimized (string literal keys with simple value expressions). Complex cases like computed properties, getters/setters, and spread elements use the existing slow path. 3.4x speedup on a microbenchmark that repeatedly instantiates an object literal with 26 properties. Small progressions on various benchmarks.
2026-01-09 18:55:00 +01:00
u32 property_slot = 0;
LibJS: Add bytecode generation for simple ObjectExpressions Bytecode is now generated for object literals which only contain simple key-value pairs (i.e. no spread, getters or setters)
2021-06-11 19:40:48 +03:00
for (auto& property : m_properties) {
LibJS: Rename Bytecode::Op::PropertyKind => Bytecode::PutKind This is only used to specify how a property is being added to an object by Put* instructions, so let's call it PutKind. Also add an enumeration X macro for it to prepare for upcoming specializations.
2025-10-10 11:16:02 +02:00
Bytecode::PutKind property_kind;
Everywhere: Stop using NonnullRefPtrVector This class had slightly confusing semantics and the added weirdness doesn't seem worth it just so we can say "." instead of "->" when iterating over a vector of NNRPs. This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
2023-03-06 14:17:01 +01:00
switch (property->type()) {
LibJS: Implement bytecode generation for all ObjectExpression properties
2022-03-31 00:59:58 +04:30
case ObjectProperty::Type::KeyValue:
LibJS: Rename Bytecode::Op::PropertyKind => Bytecode::PutKind This is only used to specify how a property is being added to an object by Put* instructions, so let's call it PutKind. Also add an enumeration X macro for it to prepare for upcoming specializations.
2025-10-10 11:16:02 +02:00
property_kind = Bytecode::PutKind::Own;
LibJS: Implement bytecode generation for all ObjectExpression properties
2022-03-31 00:59:58 +04:30
break;
case ObjectProperty::Type::Getter:
LibJS: Rename Bytecode::Op::PropertyKind => Bytecode::PutKind This is only used to specify how a property is being added to an object by Put* instructions, so let's call it PutKind. Also add an enumeration X macro for it to prepare for upcoming specializations.
2025-10-10 11:16:02 +02:00
property_kind = Bytecode::PutKind::Getter;
LibJS: Implement bytecode generation for all ObjectExpression properties
2022-03-31 00:59:58 +04:30
break;
case ObjectProperty::Type::Setter:
LibJS: Rename Bytecode::Op::PropertyKind => Bytecode::PutKind This is only used to specify how a property is being added to an object by Put* instructions, so let's call it PutKind. Also add an enumeration X macro for it to prepare for upcoming specializations.
2025-10-10 11:16:02 +02:00
property_kind = Bytecode::PutKind::Setter;
LibJS: Implement bytecode generation for all ObjectExpression properties
2022-03-31 00:59:58 +04:30
break;
case ObjectProperty::Type::ProtoSetter:
LibJS: Rename Bytecode::Op::PropertyKind => Bytecode::PutKind This is only used to specify how a property is being added to an object by Put* instructions, so let's call it PutKind. Also add an enumeration X macro for it to prepare for upcoming specializations.
2025-10-10 11:16:02 +02:00
property_kind = Bytecode::PutKind::Prototype;
LibJS: Implement bytecode generation for all ObjectExpression properties
2022-03-31 00:59:58 +04:30
break;
LibJS: Add `PutBySpread` instruction This object property kind had completely different behaviour. By adding an instruction for it, we can remove a bunch of special casing, and avoid creating dummy `PropertyKey` values.
2024-11-01 22:00:32 +01:00
case ObjectProperty::Type::Spread:
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
generator.emit<Bytecode::Op::PutBySpread>(object, property->key().generate_bytecode(generator).value());
LibJS: Add `PutBySpread` instruction This object property kind had completely different behaviour. By adding an instruction for it, we can remove a bunch of special casing, and avoid creating dummy `PropertyKey` values.
2024-11-01 22:00:32 +01:00
continue;
LibJS: Implement bytecode generation for all ObjectExpression properties
2022-03-31 00:59:58 +04:30
}
LibJS: Add bytecode generation for simple ObjectExpressions Bytecode is now generated for object literals which only contain simple key-value pairs (i.e. no spread, getters or setters)
2021-06-11 19:40:48 +03:00
Everywhere: Stop using NonnullRefPtrVector This class had slightly confusing semantics and the added weirdness doesn't seem worth it just so we can say "." instead of "->" when iterating over a vector of NNRPs. This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
2023-03-06 14:17:01 +01:00
if (is<StringLiteral>(property->key())) {
auto& string_literal = static_cast<StringLiteral const&>(property->key());
LibJS: Add bytecode generation for simple ObjectExpressions Bytecode is now generated for object literals which only contain simple key-value pairs (i.e. no spread, getters or setters)
2021-06-11 19:40:48 +03:00
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
Optional<ScopedOperand> value;
LibJS: Rename Bytecode::Op::PropertyKind => Bytecode::PutKind This is only used to specify how a property is being added to an object by Put* instructions, so let's call it PutKind. Also add an enumeration X macro for it to prepare for upcoming specializations.
2025-10-10 11:16:02 +02:00
if (property_kind == Bytecode::PutKind::Prototype) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
value = property->value().generate_bytecode(generator).value();
LibJS: Add `PutBySpread` instruction This object property kind had completely different behaviour. By adding an instruction for it, we can remove a bunch of special casing, and avoid creating dummy `PropertyKey` values.
2024-11-01 22:00:32 +01:00
} else {
LibJS: Use FlyString in PropertyKey instead of DeprecatedFlyString This required dealing with *substantial* fallout.
2025-03-18 18:08:02 -05:00
auto identifier = string_literal.value();
LibJS: Rename Bytecode::Op::PropertyKind => Bytecode::PutKind This is only used to specify how a property is being added to an object by Put* instructions, so let's call it PutKind. Also add an enumeration X macro for it to prepare for upcoming specializations.
2025-10-10 11:16:02 +02:00
if (property_kind == Bytecode::PutKind::Getter)
LibJS: Port the Identifier AST (and related) nodes to UTF-16 This eliminates quite a lot of UTF-8 / UTF-16 churn.
2025-08-06 11:12:58 -04:00
identifier = Utf16String::formatted("get {}", identifier);
LibJS: Rename Bytecode::Op::PropertyKind => Bytecode::PutKind This is only used to specify how a property is being added to an object by Put* instructions, so let's call it PutKind. Also add an enumeration X macro for it to prepare for upcoming specializations.
2025-10-10 11:16:02 +02:00
else if (property_kind == Bytecode::PutKind::Setter)
LibJS: Port the Identifier AST (and related) nodes to UTF-16 This eliminates quite a lot of UTF-8 / UTF-16 churn.
2025-08-06 11:12:58 -04:00
identifier = Utf16String::formatted("set {}", identifier);
LibJS: Assign getter/setter function names as early as possible In case of {get func() {}, set func() {}} we were wrongly setting the function name to 'func' and then later trying to replace an empty name with 'get func'/'set func' which failed. Instead, set the name to 'get func'/'set func' right away. The code in put_by_property_key is kept, for when that is called by put_by_value.
2023-11-05 11:21:32 +01:00
auto name = generator.intern_identifier(identifier);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
value = generator.emit_named_evaluation_if_anonymous_function(property->value(), name, {}, property->is_method());
LibJS/Bytecode: Transfer object expression property names to functions 2 new passes on test262. :^)
2023-06-25 19:25:38 +02:00
}
LibJS: Implement bytecode generation for all ObjectExpression properties
2022-03-31 00:59:58 +04:30
LibJS: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
auto property_key_table_index = generator.intern_property_key(string_literal.value());
LibJS: Add shape caching for object literal instantiation When a function creates object literals with simple property names, we now cache the resulting shape after the first instantiation. On subsequent calls, we create the object with the cached shape directly and write property values at their known offsets. This avoids repeated shape transitions and property offset lookups for a common JavaScript pattern. The optimization uses two new bytecode instructions: - CacheObjectShape: Captures the final shape after object construction - InitObjectLiteralProperty: Writes properties using cached offsets Only "simple" object literals are optimized (string literal keys with simple value expressions). Complex cases like computed properties, getters/setters, and spread elements use the existing slow path. 3.4x speedup on a microbenchmark that repeatedly instantiates an object literal with 26 properties. Small progressions on various benchmarks.
2026-01-09 18:55:00 +01:00
// For simple object literals, use InitObjectLiteralProperty for direct offset writes
if (is_simple) {
generator.emit<Bytecode::Op::InitObjectLiteralProperty>(object, property_key_table_index, *value, *shape_cache_index, property_slot++);
} else {
generator.emit_put_by_id(object, property_key_table_index, *value, property_kind, generator.next_property_lookup_cache());
}
LibJS: Add bytecode generation for simple ObjectExpressions Bytecode is now generated for object literals which only contain simple key-value pairs (i.e. no spread, getters or setters)
2021-06-11 19:40:48 +03:00
} else {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto property_name = property->key().generate_bytecode(generator).value();
LibJS: Fix evaluation order of computed property keys in object literals The spec for PropertyDefinitionEvaluation requires that when evaluating a property definition with a computed key (PropertyDefinition : PropertyName : AssignmentExpression), the PropertyName is fully evaluated (including ToPropertyKey, which calls ToPrimitive) before the value's AssignmentExpression is evaluated. Our bytecode compiler was evaluating the key expression first, then the value expression, and only performing ToPropertyKey later inside PutByValue at runtime. This meant user-observable side effects from ToPrimitive (such as calling Symbol.toPrimitive or toString on the key object) would fire after the value expression had already been evaluated. Fix this by using a new ToPrimitiveWithStringHint instruction that performs ToPrimitive with string hint(!), and emitting it between the key and value evaluations in ObjectExpression codegen. After ToPrimitive, the key is already a primitive, so the subsequent ToPropertyKey inside PutByValue becomes a no-op from the perspective of user-observable side effects. Also update an existing test that was asserting the old (incorrect) evaluation order, and add comprehensive new tests for computed property key evaluation order.
2026-02-08 12:32:38 +01:00
// ComputedPropertyName evaluation calls ToPropertyKey, which includes ToPrimitive(hint: string).
// This must happen before the value expression is evaluated per the spec for
// PropertyDefinitionEvaluation (PropertyDefinition : PropertyName : AssignmentExpression):
// 1. Let propKey be ? Evaluation of PropertyName.
// [then] 5/6. Evaluate the AssignmentExpression.
// ToPrimitive is the only step in ToPropertyKey with user-observable side effects.
// After this, the ToPrimitive inside put_by_value's to_property_key is a no-op.
generator.emit<Bytecode::Op::ToPrimitiveWithStringHint>(property_name, property_name);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto value = generator.emit_named_evaluation_if_anonymous_function(property->value(), {}, {}, property->is_method());
LibJS: Implement bytecode generation for all ObjectExpression properties
2022-03-31 00:59:58 +04:30
LibJS: Emit PutById instead of PutByValue when key is string literal Basically convert o["foo"]=x into o.foo=x when emitting bytecode. These are effectively the same thing, and the latter format opts into using an inline cache for the property lookups.
2025-04-03 14:29:44 +02:00
generator.emit_put_by_value(object, property_name, value, property_kind, {});
LibJS: Add bytecode generation for simple ObjectExpressions Bytecode is now generated for object literals which only contain simple key-value pairs (i.e. no spread, getters or setters)
2021-06-11 19:40:48 +03:00
}
}
LibJS/Bytecode: Set "home object" of functions within object expression We manage this by having a stack of home objects in Generator, and then adding an optional home object parameter to the NewFunction instruction.
2023-06-16 10:25:05 +02:00
generator.pop_home_object();
LibJS: Add shape caching for object literal instantiation When a function creates object literals with simple property names, we now cache the resulting shape after the first instantiation. On subsequent calls, we create the object with the cached shape directly and write property values at their known offsets. This avoids repeated shape transitions and property offset lookups for a common JavaScript pattern. The optimization uses two new bytecode instructions: - CacheObjectShape: Captures the final shape after object construction - InitObjectLiteralProperty: Writes properties using cached offsets Only "simple" object literals are optimized (string literal keys with simple value expressions). Complex cases like computed properties, getters/setters, and spread elements use the existing slow path. 3.4x speedup on a microbenchmark that repeatedly instantiates an object literal with 26 properties. Small progressions on various benchmarks.
2026-01-09 18:55:00 +01:00
if (shape_cache_index.has_value())
generator.emit<Bytecode::Op::CacheObjectShape>(object, *shape_cache_index);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return object;
LibJS: Add a NewObject bytecode instruction for ObjectExpression :^)
2021-06-04 20:30:23 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> ArrayExpression::generate_bytecode(Bytecode::Generator& generator, Optional<ScopedOperand> preferred_dst) const
LibJS: Generate bytecode for array expressions
2021-06-08 23:06:52 +02:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS: Add support for SpreadExpressions in array literals for bytecode For this it adds another opcode `Append $lhs` which appends the accumulator to the Array in $lhs, optionally spreading it.
2022-09-09 15:23:02 +02:00
if (m_elements.is_empty()) {
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
auto dst = choose_dst(generator, preferred_dst);
LibJS: Generate C++ bytecode instruction classes from a definition file This commit adds a new Bytecode.def file that describes all the LibJS bytecode instructions. From this, we are able to generate the full declarations for all C++ bytecode instruction classes, as well as their serialization code. Note that some of the bytecode compiler was updated since instructions no longer have default constructor arguments. The big immediate benefit here is that we lose a couple thousand lines of hand-written C++ code. Going forward, this also allows us to do more tooling for the bytecode VM, now that we have an authoritative description of its instructions. Key things to know about: - Instructions can inherit from one another. At the moment, everything simply inherits from the base "Instruction". - @terminator means the instruction terminates a basic block. - @nothrow means the instruction cannot throw. This affects how the interpreter interacts with it. - Variable-length instructions are automatically supported. Just put an array of something as the last field of the instruction. - The m_length field is magical. If present, it will be populated with the full length of the instruction. This is used for variable-length instructions.
2025-11-20 22:14:50 +01:00
generator.emit<Bytecode::Op::NewArray>(dst, ReadonlySpan<ScopedOperand> {});
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return dst;
LibJS: Use ranges instead of specifying all registers for NewArray Listing all the registers will lead to the inability to allocate enough space in one basic block (as there can be an arbitrary number of registers used), instead switch to specifying the range of registers used and save a lot of space in the process.
2022-03-14 14:48:42 +00:00
}
LibJS: Generate bytecode for array expressions
2021-06-08 23:06:52 +02:00
LibJS: Instantiate primitive array expressions using a single operation This will not meaningfully affect short array literals, but it does give us a bit of extra perf when evaluating huge array expressions like in Kraken/imaging-darkroom.js
2023-11-17 22:07:23 +02:00
if (all_of(m_elements, [](auto element) { return !element || is<PrimitiveLiteral>(*element); })) {
// If all elements are constant primitives, we can just emit a single instruction to initialize the array,
// instead of emitting instructions to manually evaluate them one-by-one
LibJS/Bytecode: Make NewPrimitiveArray a variable-length instruction Instead of having a FixedArray with a separate heap allocation, we can just bake the primitive values into the instruction itself.
2024-03-03 12:37:28 +01:00
Vector<Value> values;
LibJS: Make Value() default-construct the undefined value The special empty value (that we use for array holes, Optional<Value> when empty and a few other other placeholder/sentinel tasks) still exists, but you now create one via JS::js_special_empty_value() and check for it with Value::is_special_empty_value(). The main idea here is to make it very unlikely to accidentally create an unexpected special empty value.
2025-04-04 23:16:34 +02:00
values.resize_with_default_value(m_elements.size(), js_special_empty_value());
LibJS: Instantiate primitive array expressions using a single operation This will not meaningfully affect short array literals, but it does give us a bit of extra perf when evaluating huge array expressions like in Kraken/imaging-darkroom.js
2023-11-17 22:07:23 +02:00
for (auto i = 0u; i < m_elements.size(); ++i) {
if (!m_elements[i])
continue;
values[i] = static_cast<PrimitiveLiteral const&>(*m_elements[i]).value();
}
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
auto dst = choose_dst(generator, preferred_dst);
LibJS/Bytecode: Make NewPrimitiveArray a variable-length instruction Instead of having a FixedArray with a separate heap allocation, we can just bake the primitive values into the instruction itself.
2024-03-03 12:37:28 +01:00
generator.emit_with_extra_value_slots<Bytecode::Op::NewPrimitiveArray>(values.size(), dst, values);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return dst;
LibJS: Instantiate primitive array expressions using a single operation This will not meaningfully affect short array literals, but it does give us a bit of extra perf when evaluating huge array expressions like in Kraken/imaging-darkroom.js
2023-11-17 22:07:23 +02:00
}
LibJS: Add support for SpreadExpressions in array literals for bytecode For this it adds another opcode `Append $lhs` which appends the accumulator to the Array in $lhs, optionally spreading it.
2022-09-09 15:23:02 +02:00
auto first_spread = find_if(m_elements.begin(), m_elements.end(), [](auto el) { return el && is<SpreadExpression>(*el); });
LibJS/Bytecode: Make NewArray a variable-length instruction This removes a layer of indirection in the bytecode where we had to make sure all the initializer elements were laid out in sequential registers. Array expressions no longer clobber registers permanently, and they can be reused immediately afterwards.
2024-05-08 12:43:08 +02:00
Vector<ScopedOperand> args;
args.ensure_capacity(m_elements.size());
LibJS: Add support for SpreadExpressions in array literals for bytecode For this it adds another opcode `Append $lhs` which appends the accumulator to the Array in $lhs, optionally spreading it.
2022-09-09 15:23:02 +02:00
for (auto it = m_elements.begin(); it != first_spread; ++it) {
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
if (*it) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto value = (*it)->generate_bytecode(generator).value();
LibJS/Bytecode: Add and use copy_if_needed_to_preserve_evaluation_order This is a new Bytecode::Generator helper that takes an operand and returns the same operand, or a copy of it, in case a copy is required to preserve correct evaluation order. This can be used in a bunch of places where we're worried about clobbering some value after obtaining it. Practically, locals are always copied, and temporary registers as well as constants are returned as-is.
2024-06-01 10:00:32 +02:00
args.append(generator.copy_if_needed_to_preserve_evaluation_order(value));
LibJS/Bytecode: Make NewArray a variable-length instruction This removes a layer of indirection in the bytecode where we had to make sure all the initializer elements were laid out in sequential registers. Array expressions no longer clobber registers permanently, and they can be reused immediately afterwards.
2024-05-08 12:43:08 +02:00
} else {
LibJS: Make Value() default-construct the undefined value The special empty value (that we use for array holes, Optional<Value> when empty and a few other other placeholder/sentinel tasks) still exists, but you now create one via JS::js_special_empty_value() and check for it with Value::is_special_empty_value(). The main idea here is to make it very unlikely to accidentally create an unexpected special empty value.
2025-04-04 23:16:34 +02:00
args.append(generator.add_constant(js_special_empty_value()));
LibJS: Generate bytecode for array expressions
2021-06-08 23:06:52 +02:00
}
}
LibJS: Add support for SpreadExpressions in array literals for bytecode For this it adds another opcode `Append $lhs` which appends the accumulator to the Array in $lhs, optionally spreading it.
2022-09-09 15:23:02 +02:00
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
auto dst = choose_dst(generator, preferred_dst);
if (first_spread.index() != 0) {
LibJS/Bytecode: Make NewArray a variable-length instruction This removes a layer of indirection in the bytecode where we had to make sure all the initializer elements were laid out in sequential registers. Array expressions no longer clobber registers permanently, and they can be reused immediately afterwards.
2024-05-08 12:43:08 +02:00
generator.emit_with_extra_operand_slots<Bytecode::Op::NewArray>(args.size(), dst, args);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
} else {
LibJS: Generate C++ bytecode instruction classes from a definition file This commit adds a new Bytecode.def file that describes all the LibJS bytecode instructions. From this, we are able to generate the full declarations for all C++ bytecode instruction classes, as well as their serialization code. Note that some of the bytecode compiler was updated since instructions no longer have default constructor arguments. The big immediate benefit here is that we lose a couple thousand lines of hand-written C++ code. Going forward, this also allows us to do more tooling for the bytecode VM, now that we have an authoritative description of its instructions. Key things to know about: - Instructions can inherit from one another. At the moment, everything simply inherits from the base "Instruction". - @terminator means the instruction terminates a basic block. - @nothrow means the instruction cannot throw. This affects how the interpreter interacts with it. - Variable-length instructions are automatically supported. Just put an array of something as the last field of the instruction. - The m_length field is magical. If present, it will be populated with the full length of the instruction. This is used for variable-length instructions.
2025-11-20 22:14:50 +01:00
generator.emit<Bytecode::Op::NewArray>(dst, ReadonlySpan<ScopedOperand> {});
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
}
LibJS: Add support for SpreadExpressions in array literals for bytecode For this it adds another opcode `Append $lhs` which appends the accumulator to the Array in $lhs, optionally spreading it.
2022-09-09 15:23:02 +02:00
if (first_spread != m_elements.end()) {
for (auto it = first_spread; it != m_elements.end(); ++it) {
if (!*it) {
LibJS: Make Value() default-construct the undefined value The special empty value (that we use for array holes, Optional<Value> when empty and a few other other placeholder/sentinel tasks) still exists, but you now create one via JS::js_special_empty_value() and check for it with Value::is_special_empty_value(). The main idea here is to make it very unlikely to accidentally create an unexpected special empty value.
2025-04-04 23:16:34 +02:00
generator.emit<Bytecode::Op::ArrayAppend>(dst, generator.add_constant(js_special_empty_value()), false);
LibJS: Add support for SpreadExpressions in array literals for bytecode For this it adds another opcode `Append $lhs` which appends the accumulator to the Array in $lhs, optionally spreading it.
2022-09-09 15:23:02 +02:00
} else {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto value = (*it)->generate_bytecode(generator).value();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::ArrayAppend>(dst, value, *it && is<SpreadExpression>(**it));
LibJS: Add support for SpreadExpressions in array literals for bytecode For this it adds another opcode `Append $lhs` which appends the accumulator to the Array in $lhs, optionally spreading it.
2022-09-09 15:23:02 +02:00
}
}
LibJS: Use ranges instead of specifying all registers for NewArray Listing all the registers will lead to the inability to allocate enough space in one basic block (as there can be an arbitrary number of registers used), instead switch to specifying the range of registers used and save a lot of space in the process.
2022-03-14 14:48:42 +00:00
}
LibJS: Add support for SpreadExpressions in array literals for bytecode For this it adds another opcode `Append $lhs` which appends the accumulator to the Array in $lhs, optionally spreading it.
2022-09-09 15:23:02 +02:00
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return dst;
LibJS: Generate bytecode for array expressions
2021-06-08 23:06:52 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> MemberExpression::generate_bytecode(Bytecode::Generator& generator, Optional<ScopedOperand> preferred_dst) const
LibJS: Add GetById bytecode instruction for object property retrieval Same as PutById but in the other direction. :^)
2021-06-04 21:03:53 +02:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS: Skip unnecessary Mov in emit_load_from_reference for reads When MemberExpression::generate_bytecode calls emit_load_from_reference, it only uses the loaded_value and discards the reference operands. For computed member expressions (e.g. a[0]), this was generating an unnecessary Mov to save the property register for potential store-back. Add a ReferenceMode parameter to emit_load_from_reference. When LoadOnly is passed, the computed property path skips the register save and Mov.
2026-02-15 12:16:19 +01:00
auto reference = generator.emit_load_from_reference(*this, preferred_dst, Bytecode::Generator::ReferenceMode::LoadOnly);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return reference.loaded_value;
LibJS: Add GetById bytecode instruction for object property retrieval Same as PutById but in the other direction. :^)
2021-06-04 21:03:53 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> FunctionDeclaration::generate_bytecode(Bytecode::Generator& generator, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS: Support basic function calls in the bytecode world :^) This patch adds the Call bytecode instruction which is emitted for the CallExpression AST node. It's pretty barebones and doesn't handle 'this' values properly, etc. But it can perform basic function calls! :^) Note that the called function will *not* execute as bytecode, but will simply fall back into the old codepath and use the AST interpreter.
2021-06-05 15:15:30 +02:00
{
LibJS: More properly implement scoping rules in bytecode codegen Now we emit CreateVariable and SetVariable with the appropriate initialization/environment modes, much closer to the spec. This makes a whole lot of things like let/const variables, function and variable hoisting and some other things work :^)
2022-02-12 19:48:45 +03:30
if (m_is_hoisted) {
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS: More properly implement scoping rules in bytecode codegen Now we emit CreateVariable and SetVariable with the appropriate initialization/environment modes, much closer to the spec. This makes a whole lot of things like let/const variables, function and variable hoisting and some other things work :^)
2022-02-12 19:48:45 +03:30
auto index = generator.intern_identifier(name());
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto value = generator.allocate_register();
LibJS/Bytecode: Rename GetVariable => GetBinding
2024-05-14 11:32:04 +02:00
generator.emit<Bytecode::Op::GetBinding>(value, index);
LibJS/Bytecode: Split SetVariable into four separate instructions Instead of SetVariable having 2x2 modes for variable/lexical and initialize/set, those 4 modes are now separate instructions, which makes each instruction much less branchy.
2024-05-14 11:30:30 +02:00
generator.emit<Bytecode::Op::SetVariableBinding>(index, value);
LibJS: More properly implement scoping rules in bytecode codegen Now we emit CreateVariable and SetVariable with the appropriate initialization/environment modes, much closer to the spec. This makes a whole lot of things like let/const variables, function and variable hoisting and some other things work :^)
2022-02-12 19:48:45 +03:30
}
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
return Optional<ScopedOperand> {};
LibJS: Support basic function calls in the bytecode world :^) This patch adds the Call bytecode instruction which is emitted for the CallExpression AST node. It's pretty barebones and doesn't handle 'this' values properly, etc. But it can perform basic function calls! :^) Note that the called function will *not* execute as bytecode, but will simply fall back into the old codepath and use the AST interpreter.
2021-06-05 15:15:30 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> FunctionExpression::generate_bytecode_with_lhs_name(Bytecode::Generator& generator, Optional<Bytecode::IdentifierTableIndex> lhs_name, Optional<ScopedOperand> preferred_dst, bool is_method) const
LibJS: Add bytecode generation for FunctionExpression :^)
2021-06-11 10:46:46 +02:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS/Bytecode: Define named functions as a variable inside their scope This allows you to recurse into a named function that is stored in a variable. For example, this would previously print "wrong" instead of "right": ```js function g() { console.log("wrong") } f = function g(i) { if (i !== 1) g(1); else console.log("right"); } f() ```
2022-06-11 23:24:55 +01:00
bool has_name = !name().is_empty();
Optional<Bytecode::IdentifierTableIndex> name_identifier;
if (has_name) {
LibJS/Bytecode: Leave BlockDeclarationInstantiation in C++ Instead of implementing this AO in bytecode, we now have an instruction for it that simply invokes the C++ implementation. This allows us to simplify Bytecode::Generator quite a bit by removing all the variable scope tracking.
2023-06-16 16:34:47 +02:00
generator.begin_variable_scope();
LibJS/Bytecode: Define named functions as a variable inside their scope This allows you to recurse into a named function that is stored in a variable. For example, this would previously print "wrong" instead of "right": ```js function g() { console.log("wrong") } f = function g(i) { if (i !== 1) g(1); else console.log("right"); } f() ```
2022-06-11 23:24:55 +01:00
name_identifier = generator.intern_identifier(name());
LibJS: Generate C++ bytecode instruction classes from a definition file This commit adds a new Bytecode.def file that describes all the LibJS bytecode instructions. From this, we are able to generate the full declarations for all C++ bytecode instruction classes, as well as their serialization code. Note that some of the bytecode compiler was updated since instructions no longer have default constructor arguments. The big immediate benefit here is that we lose a couple thousand lines of hand-written C++ code. Going forward, this also allows us to do more tooling for the bytecode VM, now that we have an authoritative description of its instructions. Key things to know about: - Instructions can inherit from one another. At the moment, everything simply inherits from the base "Instruction". - @terminator means the instruction terminates a basic block. - @nothrow means the instruction cannot throw. This affects how the interpreter interacts with it. - Variable-length instructions are automatically supported. Just put an array of something as the last field of the instruction. - The m_length field is magical. If present, it will be populated with the full length of the instruction. This is used for variable-length instructions.
2025-11-20 22:14:50 +01:00
generator.emit<Bytecode::Op::CreateVariable>(*name_identifier, Bytecode::Op::EnvironmentMode::Lexical, true, false, false);
LibJS/Bytecode: Define named functions as a variable inside their scope This allows you to recurse into a named function that is stored in a variable. For example, this would previously print "wrong" instead of "right": ```js function g() { console.log("wrong") } f = function g(i) { if (i !== 1) g(1); else console.log("right"); } f() ```
2022-06-11 23:24:55 +01:00
}
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
auto new_function = choose_dst(generator, preferred_dst);
LibJS: Don't set [[HomeObject]] for non-method object properties This fixes an issue where we'd incorrectly retain objects via the [[HomeObject]] slot. This common pattern was affected: Object.defineProperty(o, "foo", { get: function() { return 123; } }); Above, the object literal would get assigned to the [[HomeObject]] slot even though "get" is not a "method" per the spec. This frees about 30,000 objects on my x.com home feed.
2025-12-17 00:22:20 -06:00
generator.emit_new_function(new_function, *this, lhs_name, is_method);
LibJS/Bytecode: Define named functions as a variable inside their scope This allows you to recurse into a named function that is stored in a variable. For example, this would previously print "wrong" instead of "right": ```js function g() { console.log("wrong") } f = function g(i) { if (i !== 1) g(1); else console.log("right"); } f() ```
2022-06-11 23:24:55 +01:00
if (has_name) {
LibJS/Bytecode: Split SetVariable into four separate instructions Instead of SetVariable having 2x2 modes for variable/lexical and initialize/set, those 4 modes are now separate instructions, which makes each instruction much less branchy.
2024-05-14 11:30:30 +02:00
generator.emit<Bytecode::Op::InitializeLexicalBinding>(*name_identifier, new_function);
LibJS/Bytecode: Define named functions as a variable inside their scope This allows you to recurse into a named function that is stored in a variable. For example, this would previously print "wrong" instead of "right": ```js function g() { console.log("wrong") } f = function g(i) { if (i !== 1) g(1); else console.log("right"); } f() ```
2022-06-11 23:24:55 +01:00
generator.end_variable_scope();
}
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return new_function;
LibJS: Add bytecode generation for FunctionExpression :^)
2021-06-11 10:46:46 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> FunctionExpression::generate_bytecode(Bytecode::Generator& generator, Optional<ScopedOperand> preferred_dst) const
LibJS/Bytecode: Add codegen for "named evaluation if anonymous function" This gives anonymous functions the name from the LHS they are being assigned to. 171 new passes on test262. :^)
2023-06-23 14:27:42 +02:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return generate_bytecode_with_lhs_name(generator, {}, preferred_dst);
LibJS/Bytecode: Add codegen for "named evaluation if anonymous function" This gives anonymous functions the name from the LHS they are being assigned to. 171 new passes on test262. :^)
2023-06-23 14:27:42 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
static void generate_object_binding_pattern_bytecode(Bytecode::Generator& generator, BindingPattern const& pattern, Bytecode::Op::BindingInitializationMode initialization_mode, ScopedOperand const& object)
LibJS: Support object destructuring in the bytecode interpreter
2021-06-13 12:24:55 -07:00
{
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::ThrowIfNullish>(object);
LibJS/Bytecode: Throw on destructuring object assignment to nullish LHS 24 new passes on test262. :^)
2023-06-25 08:50:07 +02:00
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
Vector<ScopedOperand> excluded_property_names;
LibJS: Support object rest elements in the bytecode interpreter
2021-06-13 15:30:32 -07:00
auto has_rest = false;
if (pattern.entries.size() > 0)
has_rest = pattern.entries[pattern.entries.size() - 1].is_rest;
LibJS: Support object destructuring in the bytecode interpreter
2021-06-13 12:24:55 -07:00
for (auto& [name, alias, initializer, is_rest] : pattern.entries) {
LibJS: Support object rest elements in the bytecode interpreter
2021-06-13 15:30:32 -07:00
if (is_rest) {
VERIFY(!initializer);
LibJS/Bytecode: Support using MemberExpression as rest property Also, don't assert while dumping an AST with this construct. 7 new passes on test262. :^)
2023-07-02 11:24:55 +02:00
if (name.has<NonnullRefPtr<Identifier const>>()) {
LibJS: Update bytecode generator to use local variables - Update ECMAScriptFunctionObject::function_declaration_instantiation to initialize local variables - Introduce GetLocal, SetLocal, TypeofLocal that will be used to operate on local variables. - Update bytecode generator to emit instructions for local variables
2023-07-05 02:17:10 +02:00
auto identifier = name.get<NonnullRefPtr<Identifier const>>();
LibJS: Support object rest elements in the bytecode interpreter
2021-06-13 15:30:32 -07:00
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto copy = generator.allocate_register();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit_with_extra_operand_slots<Bytecode::Op::CopyObjectExcludingProperties>(
excluded_property_names.size(), copy, object, excluded_property_names);
generator.emit_set_variable(*identifier, copy, initialization_mode);
LibJS: Support object rest elements in the bytecode interpreter
2021-06-13 15:30:32 -07:00
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
return;
LibJS/Bytecode: Support using MemberExpression as rest property Also, don't assert while dumping an AST with this construct. 7 new passes on test262. :^)
2023-07-02 11:24:55 +02:00
}
if (alias.has<NonnullRefPtr<MemberExpression const>>()) {
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto copy = generator.allocate_register();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit_with_extra_operand_slots<Bytecode::Op::CopyObjectExcludingProperties>(
excluded_property_names.size(), copy, object, excluded_property_names);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
generator.emit_store_to_reference(alias.get<NonnullRefPtr<MemberExpression const>>(), copy);
return;
LibJS/Bytecode: Support using MemberExpression as rest property Also, don't assert while dumping an AST with this construct. 7 new passes on test262. :^)
2023-07-02 11:24:55 +02:00
}
VERIFY_NOT_REACHED();
LibJS: Support object rest elements in the bytecode interpreter
2021-06-13 15:30:32 -07:00
}
LibJS: Support object destructuring in the bytecode interpreter
2021-06-13 12:24:55 -07:00
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto value = generator.allocate_register();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
if (name.has<NonnullRefPtr<Identifier const>>()) {
LibJS/Bytecode: Make primitive strings be constants Instead of emitting a NewString instruction to construct a primitive string from a parsed literal, we now instantiate the PrimitiveString on the heap during codegen.
2024-03-03 11:34:36 +01:00
auto const& identifier = name.get<NonnullRefPtr<Identifier const>>()->string();
LibJS: Support object rest elements in the bytecode interpreter
2021-06-13 15:30:32 -07:00
if (has_rest) {
LibJS/Bytecode: Make constant deduplication a bit smarter Instead of scanning through the list of seen constants, we now have a more structured storage of the constants true, false, null, undefined, and every possible Int32 value. This fixes an O(n^2) issue found by Kraken/json-stringify-tinderbox.js
2024-05-14 14:28:22 +02:00
excluded_property_names.append(generator.add_constant(PrimitiveString::create(generator.vm(), identifier)));
LibJS: Support object rest elements in the bytecode interpreter
2021-06-13 15:30:32 -07:00
}
LibJS: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
generator.emit_get_by_id(value, object, generator.intern_property_key(identifier));
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
} else {
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
auto expression = name.get<NonnullRefPtr<Expression const>>();
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto property_name = expression->generate_bytecode(generator).value();
LibJS: Support object rest elements in the bytecode interpreter
2021-06-13 15:30:32 -07:00
if (has_rest) {
LibJS/Bytecode: Add and use copy_if_needed_to_preserve_evaluation_order This is a new Bytecode::Generator helper that takes an operand and returns the same operand, or a copy of it, in case a copy is required to preserve correct evaluation order. This can be used in a bunch of places where we're worried about clobbering some value after obtaining it. Practically, locals are always copied, and temporary registers as well as constants are returned as-is.
2024-06-01 10:00:32 +02:00
auto excluded_name = generator.copy_if_needed_to_preserve_evaluation_order(property_name);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
excluded_property_names.append(excluded_name);
LibJS: Support object rest elements in the bytecode interpreter
2021-06-13 15:30:32 -07:00
}
LibJS: Emit GetById instead of GetByValue when key is string literal Basically convert o["foo"] into o.foo when emitting bytecode. These are effectively the same thing, and the latter format opts into using an inline cache for the property lookups.
2025-04-03 14:18:24 +02:00
generator.emit_get_by_value(value, object, property_name);
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
}
LibJS: Support object destructuring in the bytecode interpreter
2021-06-13 12:24:55 -07:00
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
if (initializer) {
auto& if_undefined_block = generator.make_block();
auto& if_not_undefined_block = generator.make_block();
LibJS: Support object destructuring in the bytecode interpreter
2021-06-13 12:24:55 -07:00
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
generator.emit<Bytecode::Op::JumpUndefined>(
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
value,
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
Bytecode::Label { if_undefined_block },
Bytecode::Label { if_not_undefined_block });
LibJS: Support object destructuring in the bytecode interpreter
2021-06-13 12:24:55 -07:00
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
generator.switch_to_basic_block(if_undefined_block);
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
Optional<ScopedOperand> default_value;
LibJS/Bytecode: Prefer alias over name in object pattern bindings 10 new passes on test262. :^)
2023-06-27 14:41:09 +02:00
if (auto const* alias_identifier = alias.get_pointer<NonnullRefPtr<Identifier const>>()) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
default_value = generator.emit_named_evaluation_if_anonymous_function(*initializer, generator.intern_identifier((*alias_identifier)->string()));
LibJS/Bytecode: Prefer alias over name in object pattern bindings 10 new passes on test262. :^)
2023-06-27 14:41:09 +02:00
} else if (auto const* lhs = name.get_pointer<NonnullRefPtr<Identifier const>>()) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
default_value = generator.emit_named_evaluation_if_anonymous_function(*initializer, generator.intern_identifier((*lhs)->string()));
LibJS/Bytecode: Add codegen for "named evaluation if anonymous function" This gives anonymous functions the name from the LHS they are being assigned to. 171 new passes on test262. :^)
2023-06-23 14:27:42 +02:00
} else {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
default_value = initializer->generate_bytecode(generator).value();
LibJS/Bytecode: Add codegen for "named evaluation if anonymous function" This gives anonymous functions the name from the LHS they are being assigned to. 171 new passes on test262. :^)
2023-06-23 14:27:42 +02:00
}
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(value, *default_value);
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { if_not_undefined_block });
LibJS: Support object destructuring in the bytecode interpreter
2021-06-13 12:24:55 -07:00
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
generator.switch_to_basic_block(if_not_undefined_block);
}
LibJS: Support object destructuring in the bytecode interpreter
2021-06-13 12:24:55 -07:00
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
if (alias.has<NonnullRefPtr<BindingPattern const>>()) {
auto& binding_pattern = *alias.get<NonnullRefPtr<BindingPattern const>>();
LibJS/Bytecode: Add and use copy_if_needed_to_preserve_evaluation_order This is a new Bytecode::Generator helper that takes an operand and returns the same operand, or a copy of it, in case a copy is required to preserve correct evaluation order. This can be used in a bunch of places where we're worried about clobbering some value after obtaining it. Practically, locals are always copied, and temporary registers as well as constants are returned as-is.
2024-06-01 10:00:32 +02:00
auto nested_value = generator.copy_if_needed_to_preserve_evaluation_order(value);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
binding_pattern.generate_bytecode(generator, initialization_mode, nested_value);
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
} else if (alias.has<Empty>()) {
LibJS: Convert unreachable codegen error sites to VERIFY Replace CodeGenerationError returns with VERIFY_NOT_REACHED() or VERIFY() at sites that are provably unreachable: - Non-computed member expression fallbacks in emit_load_from_reference, emit_store_to_reference, and emit_delete_reference (member expression properties are always computed, identifier, or private identifier) - Two non-computed member expression fallbacks in AssignmentExpression - Default case in compound assignment switch (all 15 AssignmentOp values are handled) - BindingPattern Empty/Expression name+alias pair (computed property names always require an alias) - Two assignment+destructuring combinations in for-in/of body evaluation (is_destructuring is only set for VariableDeclaration lhs, which always has VarBinding or LexicalBinding kind, never Assignment)
2026-02-11 22:05:55 +01:00
// NB: Computed property names always require an alias, so name can't be an Expression here.
VERIFY(!name.has<NonnullRefPtr<Expression const>>());
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
LibJS: Update bytecode generator to use local variables - Update ECMAScriptFunctionObject::function_declaration_instantiation to initialize local variables - Introduce GetLocal, SetLocal, TypeofLocal that will be used to operate on local variables. - Update bytecode generator to emit instructions for local variables
2023-07-05 02:17:10 +02:00
auto const& identifier = *name.get<NonnullRefPtr<Identifier const>>();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit_set_variable(identifier, value, initialization_mode);
LibJS/Bytecode: Handle object destructuring to member expression 19 new passes on test262. :^)
2023-06-25 16:24:05 +02:00
} else if (alias.has<NonnullRefPtr<MemberExpression const>>()) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
generator.emit_store_to_reference(alias.get<NonnullRefPtr<MemberExpression const>>(), value);
LibJS: Support object destructuring in the bytecode interpreter
2021-06-13 12:24:55 -07:00
} else {
LibJS: Update bytecode generator to use local variables - Update ECMAScriptFunctionObject::function_declaration_instantiation to initialize local variables - Introduce GetLocal, SetLocal, TypeofLocal that will be used to operate on local variables. - Update bytecode generator to emit instructions for local variables
2023-07-05 02:17:10 +02:00
auto const& identifier = *alias.get<NonnullRefPtr<Identifier const>>();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit_set_variable(identifier, value, initialization_mode);
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
}
}
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
static void generate_array_binding_pattern_bytecode(Bytecode::Generator& generator, BindingPattern const& pattern, Bytecode::Op::BindingInitializationMode initialization_mode, ScopedOperand const& input_array, [[maybe_unused]] Optional<ScopedOperand> preferred_dst = {})
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
{
/*
* Consider the following destructuring assignment:
*
* let [a, b, c, d, e] = o;
*
* It would be fairly trivial to just loop through this iterator, getting the value
* at each step and assigning them to the binding sequentially. However, this is not
* correct: once an iterator is exhausted, it must not be called again. This complicates
* the bytecode. In order to accomplish this, we do the following:
*
* - Reserve a special boolean register which holds 'true' if the iterator is exhausted,
* and false otherwise
* - When we are retrieving the value which should be bound, we first check this register.
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
* If it is 'true', we load undefined. Otherwise, we grab the next value from the iterator.
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
*
* Note that the is_exhausted register does not need to be loaded with false because the
* first IteratorNext bytecode is _not_ proceeded by an exhausted check, as it is
* unnecessary.
*/
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto is_iterator_exhausted = generator.allocate_register();
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(is_iterator_exhausted, generator.add_constant(Value(false)));
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
LibJS: Avoid `IteratorRecord` GC-allocation in `GetIterator` instruction With this change, `GetIterator` no longer GC-allocates an `IteratorRecord`. Instead, it stores the iterator record fields in bytecode registers. This avoids per-iteration allocations in patterns like: `for (let [x] of array) {}`. `IteratorRecord` now inherits from `IteratorRecordImpl`, which holds the iteration state. This allows the existing iteration helpers (`iterator_next()`, `iterator_step()`, etc.) operate on both the GC-allocated and the register-backed forms. Microbenchmarks: 1.1x array-destructuring-assignment-rest.js 1.226x array-destructuring-assignment.js
2025-10-27 19:46:54 +01:00
auto iterator_object = generator.allocate_register();
auto iterator_next_method = generator.allocate_register();
auto iterator_done_property = generator.allocate_register();
LibJS: Generate C++ bytecode instruction classes from a definition file This commit adds a new Bytecode.def file that describes all the LibJS bytecode instructions. From this, we are able to generate the full declarations for all C++ bytecode instruction classes, as well as their serialization code. Note that some of the bytecode compiler was updated since instructions no longer have default constructor arguments. The big immediate benefit here is that we lose a couple thousand lines of hand-written C++ code. Going forward, this also allows us to do more tooling for the bytecode VM, now that we have an authoritative description of its instructions. Key things to know about: - Instructions can inherit from one another. At the moment, everything simply inherits from the base "Instruction". - @terminator means the instruction terminates a basic block. - @nothrow means the instruction cannot throw. This affects how the interpreter interacts with it. - Variable-length instructions are automatically supported. Just put an array of something as the last field of the instruction. - The m_length field is magical. If present, it will be populated with the full length of the instruction. This is used for variable-length instructions.
2025-11-20 22:14:50 +01:00
generator.emit<Bytecode::Op::GetIterator>(iterator_object, iterator_next_method, iterator_done_property, input_array, IteratorHint::Sync);
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
bool first = true;
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto assign_value_to_alias = [&](auto& alias, ScopedOperand value) {
LibJS: Make ASTNode::generate_bytecode() fallible Instead of crashing on the spot, return a descriptive error that will eventually continue its days as a javascript "InternalError" exception. This should make random crashes with BC less likely.
2022-02-12 19:54:08 +03:30
return alias.visit(
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
[&](Empty) -> void {
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 14:06:26 -07:00
// This element is an elision
},
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
[&](NonnullRefPtr<Identifier const> const& identifier) -> void {
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit_set_variable(*identifier, value, initialization_mode);
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 14:06:26 -07:00
},
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
[&](NonnullRefPtr<BindingPattern const> const& pattern) -> void {
pattern->generate_bytecode(generator, initialization_mode, value);
LibJS: Allow member expressions in binding patterns Also allows literal string and numbers as property names in object binding patterns.
2021-09-18 01:11:32 +02:00
},
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
[&](NonnullRefPtr<MemberExpression const> const& expr) -> void {
generator.emit_store_to_reference(*expr, value);
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 14:06:26 -07:00
});
};
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
for (auto& [name, alias, initializer, is_rest] : pattern.entries) {
VERIFY(name.has<Empty>());
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 14:06:26 -07:00
if (is_rest) {
LibJS/Bytecode: Implement initializers for array binding patterns
2022-07-17 19:25:23 +01:00
VERIFY(!initializer);
LibJS: Fix evaluation order in array destructuring assignment Per AssignmentRestElement and AssignmentElement in the specification, the DestructuringAssignmentTarget reference must be evaluated before iterating or stepping the iterator. We were doing it in the wrong order, which caused observable differences when the target evaluation has side effects, and could lead to infinite loops when the iterator never completes. Add Generator::emit_evaluate_reference() to evaluate a member expression's base and property into ReferenceOperands without performing a load or store, then use the pre-evaluated reference for the store after iteration completes.
2026-02-15 12:24:34 +01:00
// 13.15.5.3 AssignmentRestElement : ... DestructuringAssignmentTarget
// Step 1: If DestructuringAssignmentTarget is not ObjectLiteral or ArrayLiteral,
// let lref be ? Evaluation of DestructuringAssignmentTarget.
// The reference must be evaluated BEFORE iterating the remaining elements.
Optional<Bytecode::Generator::ReferenceOperands> lref;
if (auto const* member_expr = alias.get_pointer<NonnullRefPtr<MemberExpression const>>())
lref = generator.emit_evaluate_reference(**member_expr);
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto value = generator.allocate_register();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 14:06:26 -07:00
if (first) {
// The iterator has not been called, and is thus known to be not exhausted
LibJS: Avoid `IteratorRecord` GC-allocation in `GetIterator` instruction With this change, `GetIterator` no longer GC-allocates an `IteratorRecord`. Instead, it stores the iterator record fields in bytecode registers. This avoids per-iteration allocations in patterns like: `for (let [x] of array) {}`. `IteratorRecord` now inherits from `IteratorRecordImpl`, which holds the iteration state. This allows the existing iteration helpers (`iterator_next()`, `iterator_step()`, etc.) operate on both the GC-allocated and the register-backed forms. Microbenchmarks: 1.1x array-destructuring-assignment-rest.js 1.226x array-destructuring-assignment.js
2025-10-27 19:46:54 +01:00
generator.emit<Bytecode::Op::IteratorToArray>(value, iterator_object, iterator_next_method, iterator_done_property);
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 14:06:26 -07:00
} else {
auto& if_exhausted_block = generator.make_block();
auto& if_not_exhausted_block = generator.make_block();
auto& continuation_block = generator.make_block();
LibJS/Bytecode: Do basic compare-and-jump peephole optimization We now fuse sequences like [LessThan, JumpIf] to JumpLessThan. This is only allowed for temporaries (i.e VM registers) with no other references to them.
2024-05-09 15:13:31 +02:00
generator.emit_jump_if(
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
is_iterator_exhausted,
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 14:06:26 -07:00
Bytecode::Label { if_exhausted_block },
Bytecode::Label { if_not_exhausted_block });
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
value = generator.allocate_register();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 14:06:26 -07:00
generator.switch_to_basic_block(if_exhausted_block);
LibJS: Generate C++ bytecode instruction classes from a definition file This commit adds a new Bytecode.def file that describes all the LibJS bytecode instructions. From this, we are able to generate the full declarations for all C++ bytecode instruction classes, as well as their serialization code. Note that some of the bytecode compiler was updated since instructions no longer have default constructor arguments. The big immediate benefit here is that we lose a couple thousand lines of hand-written C++ code. Going forward, this also allows us to do more tooling for the bytecode VM, now that we have an authoritative description of its instructions. Key things to know about: - Instructions can inherit from one another. At the moment, everything simply inherits from the base "Instruction". - @terminator means the instruction terminates a basic block. - @nothrow means the instruction cannot throw. This affects how the interpreter interacts with it. - Variable-length instructions are automatically supported. Just put an array of something as the last field of the instruction. - The m_length field is magical. If present, it will be populated with the full length of the instruction. This is used for variable-length instructions.
2025-11-20 22:14:50 +01:00
generator.emit<Bytecode::Op::NewArray>(value, ReadonlySpan<ScopedOperand> {});
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { continuation_block });
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 14:06:26 -07:00
generator.switch_to_basic_block(if_not_exhausted_block);
LibJS: Avoid `IteratorRecord` GC-allocation in `GetIterator` instruction With this change, `GetIterator` no longer GC-allocates an `IteratorRecord`. Instead, it stores the iterator record fields in bytecode registers. This avoids per-iteration allocations in patterns like: `for (let [x] of array) {}`. `IteratorRecord` now inherits from `IteratorRecordImpl`, which holds the iteration state. This allows the existing iteration helpers (`iterator_next()`, `iterator_step()`, etc.) operate on both the GC-allocated and the register-backed forms. Microbenchmarks: 1.1x array-destructuring-assignment-rest.js 1.226x array-destructuring-assignment.js
2025-10-27 19:46:54 +01:00
generator.emit<Bytecode::Op::IteratorToArray>(value, iterator_object, iterator_next_method, iterator_done_property);
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { continuation_block });
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 14:06:26 -07:00
generator.switch_to_basic_block(continuation_block);
}
LibJS: Fix evaluation order in array destructuring assignment Per AssignmentRestElement and AssignmentElement in the specification, the DestructuringAssignmentTarget reference must be evaluated before iterating or stepping the iterator. We were doing it in the wrong order, which caused observable differences when the target evaluation has side effects, and could lead to infinite loops when the iterator never completes. Add Generator::emit_evaluate_reference() to evaluate a member expression's base and property into ReferenceOperands without performing a load or store, then use the pre-evaluated reference for the store after iteration completes.
2026-02-15 12:24:34 +01:00
if (lref.has_value())
generator.emit_store_to_reference(*lref, value);
else
assign_value_to_alias(alias, value);
return;
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 14:06:26 -07:00
}
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
LibJS: Fix evaluation order in array destructuring assignment Per AssignmentRestElement and AssignmentElement in the specification, the DestructuringAssignmentTarget reference must be evaluated before iterating or stepping the iterator. We were doing it in the wrong order, which caused observable differences when the target evaluation has side effects, and could lead to infinite loops when the iterator never completes. Add Generator::emit_evaluate_reference() to evaluate a member expression's base and property into ReferenceOperands without performing a load or store, then use the pre-evaluated reference for the store after iteration completes.
2026-02-15 12:24:34 +01:00
// 13.15.5.5 AssignmentElement : DestructuringAssignmentTarget Initializer(opt)
// Step 1: If DestructuringAssignmentTarget is not ObjectLiteral or ArrayLiteral,
// let lref be ? Evaluation of DestructuringAssignmentTarget.
// The reference must be evaluated BEFORE calling IteratorStepValue.
Optional<Bytecode::Generator::ReferenceOperands> lref;
if (auto const* member_expr = alias.get_pointer<NonnullRefPtr<MemberExpression const>>())
lref = generator.emit_evaluate_reference(**member_expr);
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
auto& iterator_is_exhausted_block = generator.make_block();
if (!first) {
auto& iterator_is_not_exhausted_block = generator.make_block();
LibJS/Bytecode: Do basic compare-and-jump peephole optimization We now fuse sequences like [LessThan, JumpIf] to JumpLessThan. This is only allowed for temporaries (i.e VM registers) with no other references to them.
2024-05-09 15:13:31 +02:00
generator.emit_jump_if(
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
is_iterator_exhausted,
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
Bytecode::Label { iterator_is_exhausted_block },
Bytecode::Label { iterator_is_not_exhausted_block });
generator.switch_to_basic_block(iterator_is_not_exhausted_block);
LibJS: Support object destructuring in the bytecode interpreter
2021-06-13 12:24:55 -07:00
}
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
LibJS: Optimize array destructuring assignment for builtin iterators ...by avoiding `{ value, done }` iterator result value allocation. This change applies the same otimization 81b6a11 added for `for..in` and `for..of`. Makes following micro benchmark go 22% faster on my computer: ```js function f() { const arr = []; for (let i = 0; i < 10_000_000; i++) { arr.push([i]); } let sum = 0; for (let [i] of arr) { sum += i; } } f(); ```
2025-05-01 16:05:24 +03:00
auto value = generator.allocate_register();
LibJS: Avoid `IteratorRecord` GC-allocation in `GetIterator` instruction With this change, `GetIterator` no longer GC-allocates an `IteratorRecord`. Instead, it stores the iterator record fields in bytecode registers. This avoids per-iteration allocations in patterns like: `for (let [x] of array) {}`. `IteratorRecord` now inherits from `IteratorRecordImpl`, which holds the iteration state. This allows the existing iteration helpers (`iterator_next()`, `iterator_step()`, etc.) operate on both the GC-allocated and the register-backed forms. Microbenchmarks: 1.1x array-destructuring-assignment-rest.js 1.226x array-destructuring-assignment.js
2025-10-27 19:46:54 +01:00
generator.emit<Bytecode::Op::IteratorNextUnpack>(value, is_iterator_exhausted, iterator_object, iterator_next_method, iterator_done_property);
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
// We still have to check for exhaustion here. If the iterator is exhausted,
// we need to bail before trying to get the value
auto& no_bail_block = generator.make_block();
LibJS/Bytecode: Do basic compare-and-jump peephole optimization We now fuse sequences like [LessThan, JumpIf] to JumpLessThan. This is only allowed for temporaries (i.e VM registers) with no other references to them.
2024-05-09 15:13:31 +02:00
generator.emit_jump_if(
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
is_iterator_exhausted,
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
Bytecode::Label { iterator_is_exhausted_block },
Bytecode::Label { no_bail_block });
generator.switch_to_basic_block(no_bail_block);
auto& create_binding_block = generator.make_block();
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { create_binding_block });
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
// The iterator is exhausted, so we just load undefined and continue binding
generator.switch_to_basic_block(iterator_is_exhausted_block);
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(value, generator.add_constant(js_undefined()));
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { create_binding_block });
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
generator.switch_to_basic_block(create_binding_block);
LibJS/Bytecode: Implement initializers for array binding patterns
2022-07-17 19:25:23 +01:00
if (initializer) {
auto& value_is_undefined_block = generator.make_block();
auto& value_is_not_undefined_block = generator.make_block();
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
generator.emit<Bytecode::Op::JumpUndefined>(
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
value,
LibJS/Bytecode: Implement initializers for array binding patterns
2022-07-17 19:25:23 +01:00
Bytecode::Label { value_is_undefined_block },
Bytecode::Label { value_is_not_undefined_block });
generator.switch_to_basic_block(value_is_undefined_block);
LibJS/Bytecode: Add codegen for "named evaluation if anonymous function" This gives anonymous functions the name from the LHS they are being assigned to. 171 new passes on test262. :^)
2023-06-23 14:27:42 +02:00
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
Optional<ScopedOperand> default_value;
LibJS/Bytecode: Transfer binding pattern aliases to function names 60 new passes on test262. :^)
2023-06-25 11:11:36 +02:00
if (auto const* alias_identifier = alias.get_pointer<NonnullRefPtr<Identifier const>>()) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
default_value = generator.emit_named_evaluation_if_anonymous_function(*initializer, generator.intern_identifier((*alias_identifier)->string()));
LibJS/Bytecode: Transfer binding pattern aliases to function names 60 new passes on test262. :^)
2023-06-25 11:11:36 +02:00
} else if (auto const* name_identifier = name.get_pointer<NonnullRefPtr<Identifier const>>()) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
default_value = generator.emit_named_evaluation_if_anonymous_function(*initializer, generator.intern_identifier((*name_identifier)->string()));
LibJS/Bytecode: Add codegen for "named evaluation if anonymous function" This gives anonymous functions the name from the LHS they are being assigned to. 171 new passes on test262. :^)
2023-06-23 14:27:42 +02:00
} else {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
default_value = initializer->generate_bytecode(generator).value();
LibJS/Bytecode: Add codegen for "named evaluation if anonymous function" This gives anonymous functions the name from the LHS they are being assigned to. 171 new passes on test262. :^)
2023-06-23 14:27:42 +02:00
}
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(value, *default_value);
LibJS/Bytecode: Implement initializers for array binding patterns
2022-07-17 19:25:23 +01:00
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { value_is_not_undefined_block });
generator.switch_to_basic_block(value_is_not_undefined_block);
}
LibJS: Fix evaluation order in array destructuring assignment Per AssignmentRestElement and AssignmentElement in the specification, the DestructuringAssignmentTarget reference must be evaluated before iterating or stepping the iterator. We were doing it in the wrong order, which caused observable differences when the target evaluation has side effects, and could lead to infinite loops when the iterator never completes. Add Generator::emit_evaluate_reference() to evaluate a member expression's base and property into ReferenceOperands without performing a load or store, then use the pre-evaluated reference for the store after iteration completes.
2026-02-15 12:24:34 +01:00
if (lref.has_value())
generator.emit_store_to_reference(*lref, value);
else
assign_value_to_alias(alias, value);
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
first = false;
}
LibJS: Make ASTNode::generate_bytecode() fallible Instead of crashing on the spot, return a descriptive error that will eventually continue its days as a javascript "InternalError" exception. This should make random crashes with BC less likely.
2022-02-12 19:54:08 +03:30
LibJS/Bytecode: Ensure iterator is closed after array destructuring If destructuring didn't exhaust the iterator, we have to manually close the iterator. 49 new passes on test262. :^)
2023-06-26 17:21:12 +02:00
auto& done_block = generator.make_block();
auto& not_done_block = generator.make_block();
LibJS/Bytecode: Do basic compare-and-jump peephole optimization We now fuse sequences like [LessThan, JumpIf] to JumpLessThan. This is only allowed for temporaries (i.e VM registers) with no other references to them.
2024-05-09 15:13:31 +02:00
generator.emit_jump_if(
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
is_iterator_exhausted,
LibJS/Bytecode: Ensure iterator is closed after array destructuring If destructuring didn't exhaust the iterator, we have to manually close the iterator. 49 new passes on test262. :^)
2023-06-26 17:21:12 +02:00
Bytecode::Label { done_block },
Bytecode::Label { not_done_block });
generator.switch_to_basic_block(not_done_block);
LibJS: Make IteratorClose/AsyncIteratorClose take Operand for value Change the completion_value field from Optional<Value> to Operand in both IteratorClose and AsyncIteratorClose bytecode instructions. This allows passing a dynamic value from a register, which is needed for iterator close on abrupt completion where the exception value is not known at codegen time.
2026-02-11 23:49:20 +01:00
generator.emit<Bytecode::Op::IteratorClose>(iterator_object, iterator_next_method, iterator_done_property, Completion::Type::Normal, generator.add_constant(js_undefined()));
LibJS/Bytecode: Ensure iterator is closed after array destructuring If destructuring didn't exhaust the iterator, we have to manually close the iterator. 49 new passes on test262. :^)
2023-06-26 17:21:12 +02:00
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { done_block });
generator.switch_to_basic_block(done_block);
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
void BindingPattern::generate_bytecode(Bytecode::Generator& generator, Bytecode::Op::BindingInitializationMode initialization_mode, ScopedOperand const& input_value) const
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
{
LibJS: Move BindingPattern bytecode generation into a method Preparation for upcoming function where binding pattern will have to be used outside of ASTCodegen.cpp
2024-05-09 05:00:07 +00:00
if (kind == Kind::Object)
LibJS: Delete create_variable param in BindingPattern::generate_bytecode It's no longer used, because we assume that caller of this function has already taken care of variable creation and initialization.
2025-04-22 00:33:54 +02:00
return generate_object_binding_pattern_bytecode(generator, *this, initialization_mode, input_value);
LibJS: Make ASTNode::generate_bytecode() fallible Instead of crashing on the spot, return a descriptive error that will eventually continue its days as a javascript "InternalError" exception. This should make random crashes with BC less likely.
2022-02-12 19:54:08 +03:30
LibJS: Delete create_variable param in BindingPattern::generate_bytecode It's no longer used, because we assume that caller of this function has already taken care of variable creation and initialization.
2025-04-22 00:33:54 +02:00
return generate_array_binding_pattern_bytecode(generator, *this, initialization_mode, input_value);
LibJS: Make ASTNode::generate_bytecode() fallible Instead of crashing on the spot, return a descriptive error that will eventually continue its days as a javascript "InternalError" exception. This should make random crashes with BC less likely.
2022-02-12 19:54:08 +03:30
}
LibJS: Support object destructuring in the bytecode interpreter
2021-06-13 12:24:55 -07:00
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
static void assign_value_to_variable_declarator(Bytecode::Generator& generator, VariableDeclarator const& declarator, VariableDeclaration const& declaration, ScopedOperand value)
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
{
LibJS/Bytecode: Split SetVariable into four separate instructions Instead of SetVariable having 2x2 modes for variable/lexical and initialize/set, those 4 modes are now separate instructions, which makes each instruction much less branchy.
2024-05-14 11:30:30 +02:00
auto initialization_mode = declaration.is_lexical_declaration() ? Bytecode::Op::BindingInitializationMode::Initialize : Bytecode::Op::BindingInitializationMode::Set;
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
declarator.target().visit(
[&](NonnullRefPtr<Identifier const> const& id) -> void {
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit_set_variable(*id, value, initialization_mode);
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
},
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
[&](NonnullRefPtr<BindingPattern const> const& pattern) -> void {
pattern->generate_bytecode(generator, initialization_mode, value);
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
});
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> VariableDeclaration::generate_bytecode(Bytecode::Generator& generator, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS: Add empty bytecode generation for VariableDeclaration These will be partly handled by the relevant ScopeNode due to hoisting, same basic idea as function declarations. VariableDeclaration needs to do some work, but let's stub it out first and start empty.
2021-06-10 00:29:17 +02:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS/Bytecode: Do not clobber completion value with VariableDeclaration While the completion value of a variable declaration is specified to be empty, we might already have a completion value in the accumulator from a previous statement. Preserve it so as to avoid clobbering it. This fixes 6 tests on test262.
2023-07-02 10:48:17 +02:00
LibJS: Generate bytecode for entering nested lexical environments This adds a new PushLexicalEnvironment instruction that creates a new LexicalEnvironment and pushes it on the VM's scope stack. There is no corresponding PopLexicalEnvironment instruction yet, so this will behave incorrectly with let/const scopes for example.
2021-06-10 22:12:21 +02:00
for (auto& declarator : m_declarations) {
LibJS/Bytecode: Handle awkward initialization case for duplicate `var` `var` declarations can have duplicates, but duplicate `let` or `const` bindings are a syntax error. Because of this, we can sink `let` and `const` directly into the preferred_dst if available. This is not safe for `var` since the preferred_dst may be used in the initializer. This patch fixes the issue by simply skipping the preferred_dst optimization for `var` declarations.
2024-03-01 12:54:50 +01:00
// NOTE: `var` declarations can have duplicates, but duplicate `let` or `const` bindings are a syntax error.
// Because of this, we can sink `let` and `const` directly into the preferred_dst if available.
// This is not safe for `var` since the preferred_dst may be used in the initializer.
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
Optional<ScopedOperand> init_dst;
LibJS/Bytecode: Handle awkward initialization case for duplicate `var` `var` declarations can have duplicates, but duplicate `let` or `const` bindings are a syntax error. Because of this, we can sink `let` and `const` directly into the preferred_dst if available. This is not safe for `var` since the preferred_dst may be used in the initializer. This patch fixes the issue by simply skipping the preferred_dst optimization for `var` declarations.
2024-03-01 12:54:50 +01:00
if (declaration_kind() != DeclarationKind::Var) {
if (auto const* identifier = declarator->target().get_pointer<NonnullRefPtr<Identifier const>>()) {
if ((*identifier)->is_local()) {
LibJS: Skip allocating locals for arguments that allowed to be local This allows us to get rid of instructions that move arguments to locals and allocate smaller JS::Value vector in ExecutionContext by reusing slots that were already allocated for arguments. With this change for following function: ```js function f(x, y) { return x + y; } ``` we now produce following bytecode: ``` [ 0] 0: Add dst:reg6, lhs:arg0, rhs:arg1 [ 10] Return value:reg6 ``` instead of: ``` [ 0] 0: GetArgument 0, dst:x~1 [ 10] GetArgument 1, dst:y~0 [ 20] Add dst:reg6, lhs:x~1, rhs:y~0 [ 30] Return value:reg6 ```
2025-04-25 17:10:47 +02:00
init_dst = generator.local((*identifier)->local_index());
LibJS/Bytecode: Handle awkward initialization case for duplicate `var` `var` declarations can have duplicates, but duplicate `let` or `const` bindings are a syntax error. Because of this, we can sink `let` and `const` directly into the preferred_dst if available. This is not safe for `var` since the preferred_dst may be used in the initializer. This patch fixes the issue by simply skipping the preferred_dst optimization for `var` declarations.
2024-03-01 12:54:50 +01:00
}
LibJS/Bytecode: Add codegen for "named evaluation if anonymous function" This gives anonymous functions the name from the LHS they are being assigned to. 171 new passes on test262. :^)
2023-06-23 14:27:42 +02:00
}
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
}
if (declarator->init()) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto value = [&]() -> ScopedOperand {
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
if (auto const* lhs = declarator->target().get_pointer<NonnullRefPtr<Identifier const>>()) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
return generator.emit_named_evaluation_if_anonymous_function(*declarator->init(), generator.intern_identifier((*lhs)->string()), init_dst);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
} else {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
return declarator->init()->generate_bytecode(generator, init_dst).value();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
}();
assign_value_to_variable_declarator(generator, declarator, *this, value);
LibJS/Bytecode: Let `var` without initializer codegen to nothing Otherwise we incorrectly overwrite the binding with `undefined` at the point where the `var` statement is. Fixes 9 test262 tests. :^)
2023-06-17 15:16:30 +02:00
} else if (m_declaration_kind != DeclarationKind::Var) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
assign_value_to_variable_declarator(generator, declarator, *this, generator.add_constant(js_undefined()));
LibJS/Bytecode: Let `var` without initializer codegen to nothing Otherwise we incorrectly overwrite the binding with `undefined` at the point where the `var` statement is. Fixes 9 test262 tests. :^)
2023-06-17 15:16:30 +02:00
}
LibJS: Make ASTNode::generate_bytecode() fallible Instead of crashing on the spot, return a descriptive error that will eventually continue its days as a javascript "InternalError" exception. This should make random crashes with BC less likely.
2022-02-12 19:54:08 +03:30
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
if (auto const* identifier = declarator->target().get_pointer<NonnullRefPtr<Identifier const>>()) {
if ((*identifier)->is_local()) {
LibJS: Skip allocating locals for arguments that allowed to be local This allows us to get rid of instructions that move arguments to locals and allocate smaller JS::Value vector in ExecutionContext by reusing slots that were already allocated for arguments. With this change for following function: ```js function f(x, y) { return x + y; } ``` we now produce following bytecode: ``` [ 0] 0: Add dst:reg6, lhs:arg0, rhs:arg1 [ 10] Return value:reg6 ``` instead of: ``` [ 0] 0: GetArgument 0, dst:x~1 [ 10] GetArgument 1, dst:y~0 [ 20] Add dst:reg6, lhs:x~1, rhs:y~0 [ 30] Return value:reg6 ```
2025-04-25 17:10:47 +02:00
generator.set_local_initialized((*identifier)->local_index());
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
}
}
}
// NOTE: VariableDeclaration doesn't return a completion value.
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
return Optional<ScopedOperand> {};
LibJS: Add empty bytecode generation for VariableDeclaration These will be partly handled by the relevant ScopeNode due to hoisting, same basic idea as function declarations. VariableDeclaration needs to do some work, but let's stub it out first and start empty.
2021-06-10 00:29:17 +02:00
}
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
struct BaseAndValue {
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
ScopedOperand base;
ScopedOperand value;
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
};
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
static BaseAndValue get_base_and_value_from_member_expression(Bytecode::Generator& generator, MemberExpression const& member_expression)
LibJS/Bytecode: Implement optional chaining
2023-06-17 14:50:23 +01:00
{
// https://tc39.es/ecma262/#sec-super-keyword-runtime-semantics-evaluation
if (is<SuperExpression>(member_expression.object())) {
// 1. Let env be GetThisEnvironment().
// 2. Let actualThis be ? env.GetThisBinding().
LibJS/Bytecode: Only emit ResolveThisBinding once per basic block Once executed, this instruction will always produce the same result in subsequent executions, so it's okay to cache it. Unfortunately it may throw, so we can't just hoist it to the top of every executable, since that would break observable execution order.
2024-05-07 12:16:37 +02:00
auto this_value = generator.get_this();
LibJS/Bytecode: Implement optional chaining
2023-06-17 14:50:23 +01:00
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
Optional<ScopedOperand> computed_property;
LibJS/Bytecode: Implement optional chaining
2023-06-17 14:50:23 +01:00
if (member_expression.is_computed()) {
// SuperProperty : super [ Expression ]
// 3. Let propertyNameReference be ? Evaluation of Expression.
// 4. Let propertyNameValue be ? GetValue(propertyNameReference).
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
computed_property = member_expression.property().generate_bytecode(generator);
LibJS/Bytecode: Implement optional chaining
2023-06-17 14:50:23 +01:00
}
// 5/7. Return ? MakeSuperPropertyReference(actualThis, propertyKey, strict).
// https://tc39.es/ecma262/#sec-makesuperpropertyreference
// 1. Let env be GetThisEnvironment().
// 2. Assert: env.HasSuperBinding() is true.
// 3. Let baseValue be ? env.GetSuperBase().
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto super_base = generator.allocate_register();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::ResolveSuperBase>(super_base);
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto value = generator.allocate_register();
LibJS/Bytecode: Implement optional chaining
2023-06-17 14:50:23 +01:00
// 4. Return the Reference Record { [[Base]]: baseValue, [[ReferencedName]]: propertyKey, [[Strict]]: strict, [[ThisValue]]: actualThis }.
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
if (computed_property.has_value()) {
LibJS/Bytecode: Implement optional chaining
2023-06-17 14:50:23 +01:00
// 5. Let propertyKey be ? ToPropertyKey(propertyNameValue).
LibJS: Emit GetById instead of GetByValue when key is string literal Basically convert o["foo"] into o.foo when emitting bytecode. These are effectively the same thing, and the latter format opts into using an inline cache for the property lookups.
2025-04-03 14:18:24 +02:00
generator.emit_get_by_value_with_this(value, super_base, *computed_property, this_value);
LibJS/Bytecode: Implement optional chaining
2023-06-17 14:50:23 +01:00
} else {
// 3. Let propertyKey be StringValue of IdentifierName.
LibJS: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
auto property_key_table_index = generator.intern_property_key(as<Identifier>(member_expression.property()).string());
generator.emit_get_by_id_with_this(value, super_base, property_key_table_index, this_value);
LibJS/Bytecode: Implement optional chaining
2023-06-17 14:50:23 +01:00
}
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return BaseAndValue { this_value, value };
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto base = member_expression.object().generate_bytecode(generator).value();
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto value = generator.allocate_register();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
if (member_expression.is_computed()) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto property = member_expression.property().generate_bytecode(generator).value();
LibJS: Emit GetById instead of GetByValue when key is string literal Basically convert o["foo"] into o.foo when emitting bytecode. These are effectively the same thing, and the latter format opts into using an inline cache for the property lookups.
2025-04-03 14:18:24 +02:00
generator.emit_get_by_value(value, base, property);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
} else if (is<PrivateIdentifier>(member_expression.property())) {
generator.emit<Bytecode::Op::GetPrivateById>(
value,
base,
AK+Everywhere: Rename `verify_cast` to `as` Follow-up to fc20e61e7249006247b43f84a3189d5a37fa103e.
2025-01-21 09:12:05 -05:00
generator.intern_identifier(as<PrivateIdentifier>(member_expression.property()).string()));
LibJS/Bytecode: Implement optional chaining
2023-06-17 14:50:23 +01:00
} else {
LibJS: Include identifier information in nullish property read access When a GetById / GetByValue bytecode operation results in accessing a nullish object, we now include the name of the property and the object being accessed in the exception message (if available). This should make it easier to debug live websites. For example, the following errors would all previously produce a generic error message of "ToObject on null or undefined": > foo = null > foo.bar Uncaught exception: [TypeError] Cannot access property "bar" on null object "foo" at <unknown> > foo = { bar: undefined } > foo.bar.baz Uncaught exception: [TypeError] Cannot access property "baz" on undefined object "foo.bar" at <unknown> Note we certainly don't capture all possible nullish property read accesses here. This just covers cases I've seen most on live websites; we can cover more cases as they arise.
2024-03-29 11:26:10 -04:00
auto base_identifier = generator.intern_identifier_for_expression(member_expression.object());
LibJS: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
generator.emit_get_by_id(value, base, generator.intern_property_key(as<Identifier>(member_expression.property()).string()), move(base_identifier));
LibJS/Bytecode: Implement optional chaining
2023-06-17 14:50:23 +01:00
}
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return BaseAndValue { base, value };
LibJS/Bytecode: Implement optional chaining
2023-06-17 14:50:23 +01:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
static void generate_optional_chain(Bytecode::Generator& generator, OptionalChain const& optional_chain, ScopedOperand current_value, ScopedOperand current_base, [[maybe_unused]] Optional<ScopedOperand> preferred_dst = {});
LibJS/Bytecode: Implement optional chaining
2023-06-17 14:50:23 +01:00
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> CallExpression::generate_bytecode(Bytecode::Generator& generator, Optional<ScopedOperand> preferred_dst) const
LibJS: Support basic function calls in the bytecode world :^) This patch adds the Call bytecode instruction which is emitted for the CallExpression AST node. It's pretty barebones and doesn't handle 'this' values properly, etc. But it can perform basic function calls! :^) Note that the called function will *not* execute as bytecode, but will simply fall back into the old codepath and use the AST interpreter.
2021-06-05 15:15:30 +02:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS: Support basic function calls in the bytecode world :^) This patch adds the Call bytecode instruction which is emitted for the CallExpression AST node. It's pretty barebones and doesn't handle 'this' values properly, etc. But it can perform basic function calls! :^) Note that the called function will *not* execute as bytecode, but will simply fall back into the old codepath and use the AST interpreter.
2021-06-05 15:15:30 +02:00
LibJS: Introduce Builtins Builtins are functions that can be detected during bytecode generation and enable fast-paths in the JIT.
2023-11-17 11:48:30 +01:00
Optional<Bytecode::Builtin> builtin;
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
Optional<ScopedOperand> original_callee;
LibJS: Preserve the original `this` value As shown in the test added by this patch, it was possible to re-assign the `this` value of a member function call while it was executing. Let's copy the original this value like we already do with the callee. Fixes #2226.
2024-11-08 17:59:12 +01:00
auto original_this_value = generator.add_constant(js_undefined());
LibJS: Introduce NativeJavaScriptBackedFunction This hosts the ability to compile and run JavaScript to implement native functions. This is particularly useful for any native function that is not a normal function, for example async functions such as Array.fromAsync, which require yielding. These functions are not allowed to observe anything from outside their environment. Any global identifiers will instead be assumed to be a reference to an abstract operation or a constant. The generator will inject the appropriate bytecode if the name of the global identifier matches a known name. Anything else will cause a code generation error.
2025-11-06 19:00:36 +00:00
auto dst = choose_dst(generator, preferred_dst);
LibJS: Split `Call` Instruction by `CallType` Instead of branching on the `CallType` at runtime in a hot instruction like `Call`, lets emit separate instructions for each call type during codegen.
2024-10-31 22:47:30 +01:00
Bytecode::Op::CallType call_type = Bytecode::Op::CallType::Call;
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
LibJS: Resolve the `this' value in call expression bytecode
2021-06-11 01:36:10 +04:30
if (is<NewExpression>(this)) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
original_callee = m_callee->generate_bytecode(generator).value();
LibJS: Split `Call` Instruction by `CallType` Instead of branching on the `CallType` at runtime in a hot instruction like `Call`, lets emit separate instructions for each call type during codegen.
2024-10-31 22:47:30 +01:00
call_type = Bytecode::Op::CallType::Construct;
LibJS: Resolve the `this' value in call expression bytecode
2021-06-11 01:36:10 +04:30
} else if (is<MemberExpression>(*m_callee)) {
Everywhere: Run clang-format
2022-04-01 20:58:27 +03:00
auto& member_expression = static_cast<MemberExpression const&>(*m_callee);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto base_and_value = get_base_and_value_from_member_expression(generator, member_expression);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
original_callee = base_and_value.value;
LibJS: Preserve the original `this` value As shown in the test added by this patch, it was possible to re-assign the `this` value of a member function call while it was executing. Let's copy the original this value like we already do with the callee. Fixes #2226.
2024-11-08 17:59:12 +01:00
original_this_value = base_and_value.base;
LibJS: Introduce Builtins Builtins are functions that can be detected during bytecode generation and enable fast-paths in the JIT.
2023-11-17 11:48:30 +01:00
builtin = Bytecode::get_builtin(member_expression);
LibJS/Bytecode: Implement optional chaining
2023-06-17 14:50:23 +01:00
} else if (is<OptionalChain>(*m_callee)) {
auto& optional_chain = static_cast<OptionalChain const&>(*m_callee);
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
original_callee = generator.allocate_register();
LibJS: Preserve the original `this` value As shown in the test added by this patch, it was possible to re-assign the `this` value of a member function call while it was executing. Let's copy the original this value like we already do with the callee. Fixes #2226.
2024-11-08 17:59:12 +01:00
original_this_value = generator.allocate_register();
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
generate_optional_chain(generator, optional_chain, *original_callee, original_this_value);
LibJS: Use correct `this` value when callee is a `with` binding If we're inside of a `with` statement scope, we have to take care to extract the correct `this` value for use in calls when calling a method on the binding object via an Identifier instead of a MemberExpression. This makes Vue.js work way better in the bytecode VM. :^) Also, 1 new pass on test262.
2023-08-01 14:33:58 +02:00
} else if (is<Identifier>(*m_callee)) {
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
// If the original_callee is an identifier, we may need to extract a `this` value.
LibJS: Use correct `this` value when callee is a `with` binding If we're inside of a `with` statement scope, we have to take care to extract the correct `this` value for use in calls when calling a method on the binding object via an Identifier instead of a MemberExpression. This makes Vue.js work way better in the bytecode VM. :^) Also, 1 new pass on test262.
2023-08-01 14:33:58 +02:00
// This is important when we're inside a `with` statement and calling a method on
// the environment's binding object.
// NOTE: If the identifier refers to a known "local" or "global", we know it can't be
// a `with` binding, so we can skip this.
auto& identifier = static_cast<Identifier const&>(*m_callee);
LibJS: Introduce NativeJavaScriptBackedFunction This hosts the ability to compile and run JavaScript to implement native functions. This is particularly useful for any native function that is not a normal function, for example async functions such as Array.fromAsync, which require yielding. These functions are not allowed to observe anything from outside their environment. Any global identifiers will instead be assumed to be a reference to an abstract operation or a constant. The generator will inject the appropriate bytecode if the name of the global identifier matches a known name. Anything else will cause a code generation error.
2025-11-06 19:00:36 +00:00
if (generator.builtin_abstract_operations_enabled() && identifier.is_global()) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
generator.generate_builtin_abstract_operation(identifier, arguments(), dst);
LibJS: Introduce NativeJavaScriptBackedFunction This hosts the ability to compile and run JavaScript to implement native functions. This is particularly useful for any native function that is not a normal function, for example async functions such as Array.fromAsync, which require yielding. These functions are not allowed to observe anything from outside their environment. Any global identifiers will instead be assumed to be a reference to an abstract operation or a constant. The generator will inject the appropriate bytecode if the name of the global identifier matches a known name. Anything else will cause a code generation error.
2025-11-06 19:00:36 +00:00
return dst;
}
LibJS: Split `Call` Instruction by `CallType` Instead of branching on the `CallType` at runtime in a hot instruction like `Call`, lets emit separate instructions for each call type during codegen.
2024-10-31 22:47:30 +01:00
if (identifier.string() == "eval"sv) {
call_type = Bytecode::Op::CallType::DirectEval;
}
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
if (identifier.is_local()) {
LibJS: Consolidate TDZ check emission into Generator helper Move the duplicated ThrowIfTDZ emission logic from three places in ASTCodegen.cpp into a single Generator::emit_tdz_check_if_needed() helper. This handles both argument TDZ (which requires a Mov to empty first) and lexically-declared variable TDZ uniformly. This avoids emitting some unnecessary ThrowIfTDZ instructions.
2026-02-17 17:42:14 +01:00
generator.emit_tdz_check_if_needed(identifier);
original_callee = generator.local(identifier.local_index());
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
} else if (identifier.is_global()) {
original_callee = m_callee->generate_bytecode(generator).value();
LibJS: Use correct `this` value when callee is a `with` binding If we're inside of a `with` statement scope, we have to take care to extract the correct `this` value for use in calls when calling a method on the binding object via an Identifier instead of a MemberExpression. This makes Vue.js work way better in the bytecode VM. :^) Also, 1 new pass on test262.
2023-08-01 14:33:58 +02:00
} else {
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
original_callee = generator.allocate_register();
LibJS: Preserve the original `this` value As shown in the test added by this patch, it was possible to re-assign the `this` value of a member function call while it was executing. Let's copy the original this value like we already do with the callee. Fixes #2226.
2024-11-08 17:59:12 +01:00
original_this_value = generator.allocate_register();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::GetCalleeAndThisFromEnvironment>(
*original_callee,
LibJS: Preserve the original `this` value As shown in the test added by this patch, it was possible to re-assign the `this` value of a member function call while it was executing. Let's copy the original this value like we already do with the callee. Fixes #2226.
2024-11-08 17:59:12 +01:00
original_this_value,
LibJS/Bytecode: Move environment variable caches into instructions These were out-of-line because we had some ideas about marking instruction streams PROT_READ only, but that seems pretty arbitrary and there's a lot of performance to be gained by putting these inline.
2024-05-11 18:28:03 +02:00
generator.intern_identifier(identifier.string()));
LibJS: Use correct `this` value when callee is a `with` binding If we're inside of a `with` statement scope, we have to take care to extract the correct `this` value for use in calls when calling a method on the binding object via an Identifier instead of a MemberExpression. This makes Vue.js work way better in the bytecode VM. :^) Also, 1 new pass on test262.
2023-08-01 14:33:58 +02:00
}
LibJS: Resolve the `this' value in call expression bytecode
2021-06-11 01:36:10 +04:30
} else {
LibJS: Remove stale FIXME about sloppy-mode this in CallExpression For non-Reference calls (e.g. (0, fn)(), (cond ? fn : x)()), the codegen correctly passes undefined as the thisValue, matching step 2b of EvaluateCall in the spec. OrdinaryCallBindThis then coerces undefined to the global object in sloppy mode at runtime. Replace the stale FIXME with a clarifying comment. Also add comprehensive tests for this-value behavior in non-Reference call patterns (comma, ternary, logical, assignment, nullish coalescing) in both sloppy and strict mode.
2026-02-08 12:14:57 +01:00
// NB: For non-Reference calls, EvaluateCall sets thisValue to undefined.
// OrdinaryCallBindThis coerces undefined to the global object in sloppy mode at runtime.
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
original_callee = m_callee->generate_bytecode(generator).value();
LibJS: Resolve the `this' value in call expression bytecode
2021-06-11 01:36:10 +04:30
}
LibJS: Preserve the original `this` value As shown in the test added by this patch, it was possible to re-assign the `this` value of a member function call while it was executing. Let's copy the original this value like we already do with the callee. Fixes #2226.
2024-11-08 17:59:12 +01:00
// NOTE: If the callee/this value isn't already a temporary, we copy them to new registers
// to avoid overwriting them while evaluating arguments.
// Example: foo.bar(Object.getPrototypeOf(foo).bar = null, foo = null)
auto this_value = generator.copy_if_needed_to_preserve_evaluation_order(original_this_value);
LibJS/Bytecode: Add and use copy_if_needed_to_preserve_evaluation_order This is a new Bytecode::Generator helper that takes an operand and returns the same operand, or a copy of it, in case a copy is required to preserve correct evaluation order. This can be used in a bunch of places where we're worried about clobbering some value after obtaining it. Practically, locals are always copied, and temporary registers as well as constants are returned as-is.
2024-06-01 10:00:32 +02:00
auto callee = generator.copy_if_needed_to_preserve_evaluation_order(original_callee.value());
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
LibJS: Forward a string aproximation of the CallExpression to Call Ops This gives us better debug output when analysing calls to `undefined` and also fixes multiple test-js cases expecting an `(evaluated from $Expression)` in the error message. This also refactors out the generation of that string, to avoid code duplication with the AST interpreter.
2022-10-01 01:36:06 +02:00
Optional<Bytecode::StringTableIndex> expression_string_index;
if (auto expression_string = this->expression_string(); expression_string.has_value())
LibJS+LibWeb: Port interned bytecode strings to UTF-16 This was almost a no-op, except we intern JS exception messages. So the bulk of this patch is porting exception messages to UTF-16.
2025-08-07 19:31:52 -04:00
expression_string_index = generator.intern_string(expression_string.release_value());
LibJS: Forward a string aproximation of the CallExpression to Call Ops This gives us better debug output when analysing calls to `undefined` and also fixes multiple test-js cases expecting an `(evaluated from $Expression)` in the error message. This also refactors out the generation of that string, to avoid code duplication with the AST interpreter.
2022-10-01 01:36:06 +02:00
LibJS/Bytecode: Add Call opcode for fixed-argument-count calls This avoids the overhead of allocating a new Array on every function call, saving a substantial amount of time and avoiding GC thrash. This patch only makes use of Op::Call in CallExpression. There are other places we should codegen this op. We should also do the same for super expression calls. ~5% speed-up on Kraken/stanford-crypto-ccm.js
2023-07-02 16:33:00 +02:00
bool has_spread = any_of(arguments(), [](auto& argument) { return argument.is_spread; });
if (has_spread) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto arguments = arguments_to_array_for_call(generator, this->arguments()).value();
LibJS: Allocate context up front when calling with argument array This necessitated splitting CallWithArgumentArray into three variants, one for each call type (call, construct and direct eval).
2025-08-30 11:00:54 +02:00
if (call_type == Op::CallType::Construct) {
generator.emit<Bytecode::Op::CallConstructWithArgumentArray>(dst, callee, this_value, arguments, expression_string_index);
} else if (call_type == Op::CallType::DirectEval) {
generator.emit<Bytecode::Op::CallDirectEvalWithArgumentArray>(dst, callee, this_value, arguments, expression_string_index);
} else {
generator.emit<Bytecode::Op::CallWithArgumentArray>(dst, callee, this_value, arguments, expression_string_index);
}
LibJS/Bytecode: Add Call opcode for fixed-argument-count calls This avoids the overhead of allocating a new Array on every function call, saving a substantial amount of time and avoiding GC thrash. This patch only makes use of Op::Call in CallExpression. There are other places we should codegen this op. We should also do the same for super expression calls. ~5% speed-up on Kraken/stanford-crypto-ccm.js
2023-07-02 16:33:00 +02:00
} else {
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
Vector<ScopedOperand> argument_operands;
LibJS/Bytecode: Make NewArray a variable-length instruction This removes a layer of indirection in the bytecode where we had to make sure all the initializer elements were laid out in sequential registers. Array expressions no longer clobber registers permanently, and they can be reused immediately afterwards.
2024-05-08 12:43:08 +02:00
argument_operands.ensure_capacity(arguments().size());
LibJS/Bytecode: Add Call opcode for fixed-argument-count calls This avoids the overhead of allocating a new Array on every function call, saving a substantial amount of time and avoiding GC thrash. This patch only makes use of Op::Call in CallExpression. There are other places we should codegen this op. We should also do the same for super expression calls. ~5% speed-up on Kraken/stanford-crypto-ccm.js
2023-07-02 16:33:00 +02:00
for (auto const& argument : arguments()) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto argument_value = argument.value->generate_bytecode(generator).value();
LibJS/Bytecode: Add and use copy_if_needed_to_preserve_evaluation_order This is a new Bytecode::Generator helper that takes an operand and returns the same operand, or a copy of it, in case a copy is required to preserve correct evaluation order. This can be used in a bunch of places where we're worried about clobbering some value after obtaining it. Practically, locals are always copied, and temporary registers as well as constants are returned as-is.
2024-06-01 10:00:32 +02:00
argument_operands.append(generator.copy_if_needed_to_preserve_evaluation_order(argument_value));
LibJS/Bytecode: Add Call opcode for fixed-argument-count calls This avoids the overhead of allocating a new Array on every function call, saving a substantial amount of time and avoiding GC thrash. This patch only makes use of Op::Call in CallExpression. There are other places we should codegen this op. We should also do the same for super expression calls. ~5% speed-up on Kraken/stanford-crypto-ccm.js
2023-07-02 16:33:00 +02:00
}
LibJS: Move CallBuiltin argument count check to bytecode compiler No need to check this at runtime, we have all the necessary info already when generating bytecode. Also mark the "yes, we are indeed calling the builtin" path [[likely]] since it's exceedingly rare for anyone to replace the global functions.
2025-12-04 21:24:16 +01:00
if (builtin.has_value() && builtin_argument_count(builtin.value()) == argument_operands.size()) {
LibJS: Split `Call` Instruction by `CallType` Instead of branching on the `CallType` at runtime in a hot instruction like `Call`, lets emit separate instructions for each call type during codegen.
2024-10-31 22:47:30 +01:00
VERIFY(call_type == Op::CallType::Call);
generator.emit_with_extra_operand_slots<Bytecode::Op::CallBuiltin>(
argument_operands.size(),
dst,
callee,
this_value,
builtin.value(),
LibJS: Generate C++ bytecode instruction classes from a definition file This commit adds a new Bytecode.def file that describes all the LibJS bytecode instructions. From this, we are able to generate the full declarations for all C++ bytecode instruction classes, as well as their serialization code. Note that some of the bytecode compiler was updated since instructions no longer have default constructor arguments. The big immediate benefit here is that we lose a couple thousand lines of hand-written C++ code. Going forward, this also allows us to do more tooling for the bytecode VM, now that we have an authoritative description of its instructions. Key things to know about: - Instructions can inherit from one another. At the moment, everything simply inherits from the base "Instruction". - @terminator means the instruction terminates a basic block. - @nothrow means the instruction cannot throw. This affects how the interpreter interacts with it. - Variable-length instructions are automatically supported. Just put an array of something as the last field of the instruction. - The m_length field is magical. If present, it will be populated with the full length of the instruction. This is used for variable-length instructions.
2025-11-20 22:14:50 +01:00
expression_string_index,
argument_operands);
LibJS: Split `Call` Instruction by `CallType` Instead of branching on the `CallType` at runtime in a hot instruction like `Call`, lets emit separate instructions for each call type during codegen.
2024-10-31 22:47:30 +01:00
} else if (call_type == Op::CallType::Construct) {
generator.emit_with_extra_operand_slots<Bytecode::Op::CallConstruct>(
argument_operands.size(),
dst,
callee,
LibJS: Generate C++ bytecode instruction classes from a definition file This commit adds a new Bytecode.def file that describes all the LibJS bytecode instructions. From this, we are able to generate the full declarations for all C++ bytecode instruction classes, as well as their serialization code. Note that some of the bytecode compiler was updated since instructions no longer have default constructor arguments. The big immediate benefit here is that we lose a couple thousand lines of hand-written C++ code. Going forward, this also allows us to do more tooling for the bytecode VM, now that we have an authoritative description of its instructions. Key things to know about: - Instructions can inherit from one another. At the moment, everything simply inherits from the base "Instruction". - @terminator means the instruction terminates a basic block. - @nothrow means the instruction cannot throw. This affects how the interpreter interacts with it. - Variable-length instructions are automatically supported. Just put an array of something as the last field of the instruction. - The m_length field is magical. If present, it will be populated with the full length of the instruction. This is used for variable-length instructions.
2025-11-20 22:14:50 +01:00
expression_string_index,
argument_operands);
LibJS: Split `Call` Instruction by `CallType` Instead of branching on the `CallType` at runtime in a hot instruction like `Call`, lets emit separate instructions for each call type during codegen.
2024-10-31 22:47:30 +01:00
} else if (call_type == Op::CallType::DirectEval) {
generator.emit_with_extra_operand_slots<Bytecode::Op::CallDirectEval>(
argument_operands.size(),
dst,
callee,
this_value,
LibJS: Generate C++ bytecode instruction classes from a definition file This commit adds a new Bytecode.def file that describes all the LibJS bytecode instructions. From this, we are able to generate the full declarations for all C++ bytecode instruction classes, as well as their serialization code. Note that some of the bytecode compiler was updated since instructions no longer have default constructor arguments. The big immediate benefit here is that we lose a couple thousand lines of hand-written C++ code. Going forward, this also allows us to do more tooling for the bytecode VM, now that we have an authoritative description of its instructions. Key things to know about: - Instructions can inherit from one another. At the moment, everything simply inherits from the base "Instruction". - @terminator means the instruction terminates a basic block. - @nothrow means the instruction cannot throw. This affects how the interpreter interacts with it. - Variable-length instructions are automatically supported. Just put an array of something as the last field of the instruction. - The m_length field is magical. If present, it will be populated with the full length of the instruction. This is used for variable-length instructions.
2025-11-20 22:14:50 +01:00
expression_string_index,
argument_operands);
LibJS: Split `Call` Instruction by `CallType` Instead of branching on the `CallType` at runtime in a hot instruction like `Call`, lets emit separate instructions for each call type during codegen.
2024-10-31 22:47:30 +01:00
} else {
generator.emit_with_extra_operand_slots<Bytecode::Op::Call>(
argument_operands.size(),
dst,
callee,
this_value,
LibJS: Generate C++ bytecode instruction classes from a definition file This commit adds a new Bytecode.def file that describes all the LibJS bytecode instructions. From this, we are able to generate the full declarations for all C++ bytecode instruction classes, as well as their serialization code. Note that some of the bytecode compiler was updated since instructions no longer have default constructor arguments. The big immediate benefit here is that we lose a couple thousand lines of hand-written C++ code. Going forward, this also allows us to do more tooling for the bytecode VM, now that we have an authoritative description of its instructions. Key things to know about: - Instructions can inherit from one another. At the moment, everything simply inherits from the base "Instruction". - @terminator means the instruction terminates a basic block. - @nothrow means the instruction cannot throw. This affects how the interpreter interacts with it. - Variable-length instructions are automatically supported. Just put an array of something as the last field of the instruction. - The m_length field is magical. If present, it will be populated with the full length of the instruction. This is used for variable-length instructions.
2025-11-20 22:14:50 +01:00
expression_string_index,
argument_operands);
LibJS: Split `Call` Instruction by `CallType` Instead of branching on the `CallType` at runtime in a hot instruction like `Call`, lets emit separate instructions for each call type during codegen.
2024-10-31 22:47:30 +01:00
}
LibJS/Bytecode: Add Call opcode for fixed-argument-count calls This avoids the overhead of allocating a new Array on every function call, saving a substantial amount of time and avoiding GC thrash. This patch only makes use of Op::Call in CallExpression. There are other places we should codegen this op. We should also do the same for super expression calls. ~5% speed-up on Kraken/stanford-crypto-ccm.js
2023-07-02 16:33:00 +02:00
}
LibJS: Forward a string aproximation of the CallExpression to Call Ops This gives us better debug output when analysing calls to `undefined` and also fixes multiple test-js cases expecting an `(evaluated from $Expression)` in the error message. This also refactors out the generation of that string, to avoid code duplication with the AST interpreter.
2022-10-01 01:36:06 +02:00
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return dst;
LibJS: Support basic function calls in the bytecode world :^) This patch adds the Call bytecode instruction which is emitted for the CallExpression AST node. It's pretty barebones and doesn't handle 'this' values properly, etc. But it can perform basic function calls! :^) Note that the called function will *not* execute as bytecode, but will simply fall back into the old codepath and use the AST interpreter.
2021-06-05 15:15:30 +02:00
}
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
static ScopedOperand generate_await(
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
Bytecode::Generator& generator,
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
ScopedOperand argument,
ScopedOperand received_completion,
ScopedOperand received_completion_type,
LibJS: Make async functions & generators faster with helper types Instead of returning internal generator results as ordinary JS::Objects with properties, we now use GeneratorResult and CompletionCell which both inherit from Cell directly and allow efficient access to state. 1.59x speedup on JetStream3/lazy-collections.js :^)
2025-03-31 09:32:39 +01:00
ScopedOperand received_completion_value);
LibJS: Implement await properly for async functions Fixes #20275 ``` Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: test/built-ins/Array/fromAsync/non-iterable-input-with-thenable -async-mapped-awaits-callback-result-once.js ❌ -> ✅ test/language/expressions/await/async-await-interleaved.js ❌ -> ✅ test/language/expressions/await/await-awaits-thenables-that- throw.js ❌ -> ✅ test/language/expressions/await/await-awaits-thenables.js ❌ -> ✅ ```
2023-08-09 22:12:07 +01:00
// https://tc39.es/ecma262/#sec-return-statement-runtime-semantics-evaluation
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> ReturnStatement::generate_bytecode(Bytecode::Generator& generator, Optional<ScopedOperand>) const
LibJS: Compile ScriptFunctions into bytecode and run them that way :^) If there's a current Bytecode::Interpreter in action, ScriptFunction will now compile itself into bytecode and execute in that context. This patch also adds the Return bytecode instruction so that we can actually return values from called functions. :^) Return values are propagated from callee to caller via the caller's $0 register. Bytecode::Interpreter now keeps a stack of register "windows". These are not very efficient, but it should be pretty straightforward to convert them to e.g a sliding register window architecture later on. This is pretty dang cool! :^)
2021-06-05 15:53:36 +02:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
Optional<ScopedOperand> return_value;
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
LibJS: Implement await properly for async functions Fixes #20275 ``` Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: test/built-ins/Array/fromAsync/non-iterable-input-with-thenable -async-mapped-awaits-callback-result-once.js ❌ -> ✅ test/language/expressions/await/async-await-interleaved.js ❌ -> ✅ test/language/expressions/await/await-awaits-thenables-that- throw.js ❌ -> ✅ test/language/expressions/await/await-awaits-thenables.js ❌ -> ✅ ```
2023-08-09 22:12:07 +01:00
if (m_argument) {
// ReturnStatement : return Expression ;
// 1. Let exprRef be ? Evaluation of Expression.
// 2. Let exprValue be ? GetValue(exprRef).
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
return_value = m_argument->generate_bytecode(generator).value();
LibJS: Implement await properly for async functions Fixes #20275 ``` Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: test/built-ins/Array/fromAsync/non-iterable-input-with-thenable -async-mapped-awaits-callback-result-once.js ❌ -> ✅ test/language/expressions/await/async-await-interleaved.js ❌ -> ✅ test/language/expressions/await/await-awaits-thenables-that- throw.js ❌ -> ✅ test/language/expressions/await/await-awaits-thenables.js ❌ -> ✅ ```
2023-08-09 22:12:07 +01:00
// 3. If GetGeneratorKind() is async, set exprValue to ? Await(exprValue).
// Spec Issue?: The spec doesn't seem to do implicit await on explicit return for async functions, but does for
// async generators. However, the major engines do so, and this is observable via constructor lookups
// on Promise objects and custom thenables.
// See: https://tc39.es/ecma262/#sec-asyncblockstart
// c. Assert: If we return here, the async function either threw an exception or performed an implicit or explicit return; all awaiting is done.
if (generator.is_in_async_function()) {
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto received_completion = generator.allocate_register();
auto received_completion_type = generator.allocate_register();
auto received_completion_value = generator.allocate_register();
LibJS: Make async functions & generators faster with helper types Instead of returning internal generator results as ordinary JS::Objects with properties, we now use GeneratorResult and CompletionCell which both inherit from Cell directly and allow efficient access to state. 1.59x speedup on JetStream3/lazy-collections.js :^)
2025-03-31 09:32:39 +01:00
return_value = generate_await(generator, *return_value, received_completion, received_completion_type, received_completion_value);
LibJS: Implement await properly for async functions Fixes #20275 ``` Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: test/built-ins/Array/fromAsync/non-iterable-input-with-thenable -async-mapped-awaits-callback-result-once.js ❌ -> ✅ test/language/expressions/await/async-await-interleaved.js ❌ -> ✅ test/language/expressions/await/await-awaits-thenables-that- throw.js ❌ -> ✅ test/language/expressions/await/await-awaits-thenables.js ❌ -> ✅ ```
2023-08-09 22:12:07 +01:00
}
// 4. Return Completion Record { [[Type]]: return, [[Value]]: exprValue, [[Target]]: empty }.
} else {
// ReturnStatement : return ;
// 1. Return Completion Record { [[Type]]: return, [[Value]]: undefined, [[Target]]: empty }.
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return_value = generator.add_constant(js_undefined());
LibJS: Implement await properly for async functions Fixes #20275 ``` Summary: Diff Tests: +4 ✅ -4 ❌ Diff Tests: test/built-ins/Array/fromAsync/non-iterable-input-with-thenable -async-mapped-awaits-callback-result-once.js ❌ -> ✅ test/language/expressions/await/async-await-interleaved.js ❌ -> ✅ test/language/expressions/await/await-awaits-thenables-that- throw.js ❌ -> ✅ test/language/expressions/await/await-awaits-thenables.js ❌ -> ✅ ```
2023-08-09 22:12:07 +01:00
}
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
LibJS: Make return control flow more static With this only `ContinuePendingUnwind` needs to dynamically check if a scheduled return needs to go through a `finally` block, making the interpreter loop a bit nicer
2024-05-12 11:03:26 +02:00
if (generator.is_in_generator_or_async_function())
generator.emit_return<Bytecode::Op::Yield>(return_value.value());
else
generator.emit_return<Bytecode::Op::Return>(return_value.value());
LibJS: Make ASTNode::generate_bytecode() fallible Instead of crashing on the spot, return a descriptive error that will eventually continue its days as a javascript "InternalError" exception. This should make random crashes with BC less likely.
2022-02-12 19:54:08 +03:30
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return return_value;
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
}
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
static void get_received_completion_type_and_value(
Bytecode::Generator& generator,
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
ScopedOperand received_completion,
ScopedOperand received_completion_type,
LibJS: Make async functions & generators faster with helper types Instead of returning internal generator results as ordinary JS::Objects with properties, we now use GeneratorResult and CompletionCell which both inherit from Cell directly and allow efficient access to state. 1.59x speedup on JetStream3/lazy-collections.js :^)
2025-03-31 09:32:39 +01:00
ScopedOperand received_completion_value)
LibJS/Bytecode: Implement async generators
2023-07-14 21:57:49 +01:00
{
LibJS: Make async functions & generators faster with helper types Instead of returning internal generator results as ordinary JS::Objects with properties, we now use GeneratorResult and CompletionCell which both inherit from Cell directly and allow efficient access to state. 1.59x speedup on JetStream3/lazy-collections.js :^)
2025-03-31 09:32:39 +01:00
generator.emit<Op::GetCompletionFields>(received_completion_type, received_completion_value, received_completion);
LibJS/Bytecode: Implement async generators
2023-07-14 21:57:49 +01:00
}
enum class AwaitBeforeYield {
No,
Yes,
};
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
static void generate_yield(Bytecode::Generator& generator,
Bytecode::Label continuation_label,
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
ScopedOperand argument,
ScopedOperand received_completion,
ScopedOperand received_completion_type,
ScopedOperand received_completion_value,
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
AwaitBeforeYield await_before_yield)
LibJS/Bytecode: Implement async generators
2023-07-14 21:57:49 +01:00
{
if (!generator.is_in_async_generator_function()) {
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::Yield>(Bytecode::Label { continuation_label }, argument);
LibJS/Bytecode: Implement async generators
2023-07-14 21:57:49 +01:00
return;
}
if (await_before_yield == AwaitBeforeYield::Yes)
LibJS: Make async functions & generators faster with helper types Instead of returning internal generator results as ordinary JS::Objects with properties, we now use GeneratorResult and CompletionCell which both inherit from Cell directly and allow efficient access to state. 1.59x speedup on JetStream3/lazy-collections.js :^)
2025-03-31 09:32:39 +01:00
argument = generate_await(generator, argument, received_completion, received_completion_type, received_completion_value);
LibJS/Bytecode: Implement async generators
2023-07-14 21:57:49 +01:00
auto& unwrap_yield_resumption_block = generator.make_block();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::Yield>(Bytecode::Label { unwrap_yield_resumption_block }, argument);
LibJS/Bytecode: Implement async generators
2023-07-14 21:57:49 +01:00
generator.switch_to_basic_block(unwrap_yield_resumption_block);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(received_completion, generator.accumulator());
LibJS: Make async functions & generators faster with helper types Instead of returning internal generator results as ordinary JS::Objects with properties, we now use GeneratorResult and CompletionCell which both inherit from Cell directly and allow efficient access to state. 1.59x speedup on JetStream3/lazy-collections.js :^)
2025-03-31 09:32:39 +01:00
get_received_completion_type_and_value(generator, received_completion, received_completion_type, received_completion_value);
LibJS/Bytecode: Implement async generators
2023-07-14 21:57:49 +01:00
// 27.6.3.7 AsyncGeneratorUnwrapYieldResumption ( resumptionValue ), https://tc39.es/ecma262/#sec-asyncgeneratorunwrapyieldresumption
// 1. If resumptionValue.[[Type]] is not return, return ? resumptionValue.
auto& resumption_value_type_is_return_block = generator.make_block();
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto resumption_value_type_is_not_return_result = generator.allocate_register();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::StrictlyInequals>(
resumption_value_type_is_not_return_result,
received_completion_type,
generator.add_constant(Value(to_underlying(Completion::Type::Return))));
LibJS/Bytecode: Do basic compare-and-jump peephole optimization We now fuse sequences like [LessThan, JumpIf] to JumpLessThan. This is only allowed for temporaries (i.e VM registers) with no other references to them.
2024-05-09 15:13:31 +02:00
generator.emit_jump_if(
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
resumption_value_type_is_not_return_result,
Bytecode::Label { continuation_label },
LibJS/Bytecode: Implement async generators
2023-07-14 21:57:49 +01:00
Bytecode::Label { resumption_value_type_is_return_block });
generator.switch_to_basic_block(resumption_value_type_is_return_block);
// 2. Let awaited be Completion(Await(resumptionValue.[[Value]])).
LibJS: Make async functions & generators faster with helper types Instead of returning internal generator results as ordinary JS::Objects with properties, we now use GeneratorResult and CompletionCell which both inherit from Cell directly and allow efficient access to state. 1.59x speedup on JetStream3/lazy-collections.js :^)
2025-03-31 09:32:39 +01:00
generate_await(generator, received_completion_value, received_completion, received_completion_type, received_completion_value);
LibJS/Bytecode: Implement async generators
2023-07-14 21:57:49 +01:00
// 3. If awaited.[[Type]] is throw, return ? awaited.
auto& awaited_type_is_normal_block = generator.make_block();
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto awaited_type_is_throw_result = generator.allocate_register();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::StrictlyEquals>(
awaited_type_is_throw_result,
received_completion_type,
generator.add_constant(Value(to_underlying(Completion::Type::Throw))));
LibJS/Bytecode: Do basic compare-and-jump peephole optimization We now fuse sequences like [LessThan, JumpIf] to JumpLessThan. This is only allowed for temporaries (i.e VM registers) with no other references to them.
2024-05-09 15:13:31 +02:00
generator.emit_jump_if(
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
awaited_type_is_throw_result,
Bytecode::Label { continuation_label },
LibJS/Bytecode: Implement async generators
2023-07-14 21:57:49 +01:00
Bytecode::Label { awaited_type_is_normal_block });
// 4. Assert: awaited.[[Type]] is normal.
generator.switch_to_basic_block(awaited_type_is_normal_block);
// 5. Return Completion Record { [[Type]]: return, [[Value]]: awaited.[[Value]], [[Target]]: empty }.
LibJS: Make async functions & generators faster with helper types Instead of returning internal generator results as ordinary JS::Objects with properties, we now use GeneratorResult and CompletionCell which both inherit from Cell directly and allow efficient access to state. 1.59x speedup on JetStream3/lazy-collections.js :^)
2025-03-31 09:32:39 +01:00
generator.emit<Bytecode::Op::SetCompletionType>(received_completion, Completion::Type::Return);
LibJS/Bytecode: Implement async generators
2023-07-14 21:57:49 +01:00
generator.emit<Bytecode::Op::Jump>(continuation_label);
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> YieldExpression::generate_bytecode(Bytecode::Generator& generator, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
{
LibJS: Save and restore exceptions on yields in finalizers Also removes a bunch of related old FIXMEs.
2024-05-06 22:38:43 +02:00
// Note: We need to catch any scheduled exceptions and reschedule them on re-entry
// as the act of yielding would otherwise clear them out
// This only applies when we are in a finalizer
bool is_in_finalizer = generator.is_in_finalizer();
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
Optional<ScopedOperand> saved_exception;
LibJS: Save and restore exceptions on yields in finalizers Also removes a bunch of related old FIXMEs.
2024-05-06 22:38:43 +02:00
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
VERIFY(generator.is_in_generator_function());
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto received_completion = generator.allocate_register();
auto received_completion_type = generator.allocate_register();
auto received_completion_value = generator.allocate_register();
LibJS: Perform received abrupt generator completions in the generator Previously, throw and return completions would not be executed inside the generator. This is incorrect, as throw and return need to perform unwinds which can potentially execute more code inside the generator, such as finally blocks. This is done by also passing the completion type alongside the passed in value. The continuation block will immediately extract and type and value and perform the appropriate operation for the given type. For normal completions, this is continuing as normal. For throw completions, it will perform `throw <value>`. For return completions, it will perform `return <value>`, which is a `Yield return` in this case due to being inside a generator. This also refactors GeneratorObject to properly send across the completion type and value to the generator inside of trying to operate on the completions itself. This is a prerequisite for yield*, as it performs special iterator operations when receiving a throw/return completion and does not complete the generator like the regular yield would. There's still more work to be done to make GeneratorObject::execute be closer to the spec. It's mostly a restructuring of the existing GeneratorObject::next_impl.
2022-11-25 23:14:08 +00:00
LibJS: Make ASTNode::generate_bytecode() fallible Instead of crashing on the spot, return a descriptive error that will eventually continue its days as a javascript "InternalError" exception. This should make random crashes with BC less likely.
2022-02-12 19:54:08 +03:30
if (m_is_yield_from) {
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
// 15.5.5 Runtime Semantics: Evaluation, https://tc39.es/ecma262/#sec-generator-function-definitions-runtime-semantics-evaluation
LibJS/Bytecode: Implement async generators
2023-07-14 21:57:49 +01:00
// 1. Let generatorKind be GetGeneratorKind().
// NOTE: is_in_async_generator_function differentiates the generator kind.
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
// 2. Let exprRef be ? Evaluation of AssignmentExpression.
// 3. Let value be ? GetValue(exprRef).
VERIFY(m_argument);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto value = m_argument->generate_bytecode(generator).value();
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
// 4. Let iteratorRecord be ? GetIterator(value, generatorKind).
// 5. Let iterator be iteratorRecord.[[Iterator]].
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto iterator = generator.allocate_register();
auto next_method = generator.allocate_register();
LibJS: Avoid `IteratorRecord` GC-allocation in `GetIterator` instruction With this change, `GetIterator` no longer GC-allocates an `IteratorRecord`. Instead, it stores the iterator record fields in bytecode registers. This avoids per-iteration allocations in patterns like: `for (let [x] of array) {}`. `IteratorRecord` now inherits from `IteratorRecordImpl`, which holds the iteration state. This allows the existing iteration helpers (`iterator_next()`, `iterator_step()`, etc.) operate on both the GC-allocated and the register-backed forms. Microbenchmarks: 1.1x array-destructuring-assignment-rest.js 1.226x array-destructuring-assignment.js
2025-10-27 19:46:54 +01:00
auto iterator_done_property = generator.allocate_register();
auto iterator_hint = generator.is_in_async_generator_function() ? IteratorHint::Async : IteratorHint::Sync;
generator.emit<Bytecode::Op::GetIterator>(iterator, next_method, iterator_done_property, value, iterator_hint);
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
// 6. Let received be NormalCompletion(undefined).
// See get_received_completion_type_and_value above.
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(received_completion_type, generator.add_constant(Value(to_underlying(Completion::Type::Normal))));
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(received_completion_value, generator.add_constant(js_undefined()));
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
// 7. Repeat,
auto& loop_block = generator.make_block();
auto& continuation_block = generator.make_block();
auto& loop_end_block = generator.make_block();
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { loop_block });
generator.switch_to_basic_block(loop_block);
// a. If received.[[Type]] is normal, then
auto& type_is_normal_block = generator.make_block();
auto& is_type_throw_block = generator.make_block();
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto received_completion_type_register_is_normal = generator.allocate_register();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::StrictlyEquals>(
received_completion_type_register_is_normal,
received_completion_type,
generator.add_constant(Value(to_underlying(Completion::Type::Normal))));
LibJS/Bytecode: Do basic compare-and-jump peephole optimization We now fuse sequences like [LessThan, JumpIf] to JumpLessThan. This is only allowed for temporaries (i.e VM registers) with no other references to them.
2024-05-09 15:13:31 +02:00
generator.emit_jump_if(
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
received_completion_type_register_is_normal,
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
Bytecode::Label { type_is_normal_block },
Bytecode::Label { is_type_throw_block });
generator.switch_to_basic_block(type_is_normal_block);
// i. Let innerResult be ? Call(iteratorRecord.[[NextMethod]], iteratorRecord.[[Iterator]], « received.[[Value]] »).
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto inner_result = generator.allocate_register();
LibJS: Avoid unnecessary `NewArray` in yield* iterator method calls Use `Op::Call` directly instead of creating a single-element array and using `CallWithArgumentArray` when calling iterator methods (`next`, `throw`, `return`) in `yield*` expressions.
2025-12-28 17:48:01 +01:00
generator.emit_with_extra_operand_slots<Bytecode::Op::Call>(1, inner_result, next_method, iterator, OptionalNone {}, ReadonlySpan<ScopedOperand> { &received_completion_value, 1 });
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
LibJS/Bytecode: Implement async generators
2023-07-14 21:57:49 +01:00
// ii. If generatorKind is async, set innerResult to ? Await(innerResult).
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
if (generator.is_in_async_generator_function()) {
LibJS: Make async functions & generators faster with helper types Instead of returning internal generator results as ordinary JS::Objects with properties, we now use GeneratorResult and CompletionCell which both inherit from Cell directly and allow efficient access to state. 1.59x speedup on JetStream3/lazy-collections.js :^)
2025-03-31 09:32:39 +01:00
auto new_inner_result = generate_await(generator, inner_result, received_completion, received_completion_type, received_completion_value);
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(inner_result, new_inner_result);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
}
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
// iii. If innerResult is not an Object, throw a TypeError exception.
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::ThrowIfNotObject>(inner_result);
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
// iv. Let done be ? IteratorComplete(innerResult).
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto done = generator.allocate_register();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit_iterator_complete(done, inner_result);
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
// v. If done is true, then
auto& type_is_normal_done_block = generator.make_block();
auto& type_is_normal_not_done_block = generator.make_block();
LibJS/Bytecode: Do basic compare-and-jump peephole optimization We now fuse sequences like [LessThan, JumpIf] to JumpLessThan. This is only allowed for temporaries (i.e VM registers) with no other references to them.
2024-05-09 15:13:31 +02:00
generator.emit_jump_if(
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
done,
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
Bytecode::Label { type_is_normal_done_block },
Bytecode::Label { type_is_normal_not_done_block });
generator.switch_to_basic_block(type_is_normal_done_block);
// 1. Return ? IteratorValue(innerResult).
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto return_value = generator.allocate_register();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit_iterator_value(return_value, inner_result);
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { loop_end_block });
generator.switch_to_basic_block(type_is_normal_not_done_block);
LibJS/Bytecode: Implement async generators
2023-07-14 21:57:49 +01:00
// vi. If generatorKind is async, set received to Completion(AsyncGeneratorYield(? IteratorValue(innerResult))).
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
// vii. Else, set received to Completion(GeneratorYield(innerResult)).
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
{
// FIXME: Yield currently only accepts a Value, not an object conforming to the IteratorResult interface, so we have to do an observable lookup of `value` here.
// This only matters for non-async generators.
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto current_value = generator.allocate_register();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit_iterator_value(current_value, inner_result);
LibJS: Save and restore exceptions on yields in finalizers Also removes a bunch of related old FIXMEs.
2024-05-06 22:38:43 +02:00
if (is_in_finalizer) {
saved_exception = generator.allocate_register();
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(Bytecode::Operand(*saved_exception), Bytecode::Operand(Bytecode::Register::exception()));
LibJS: Save and restore exceptions on yields in finalizers Also removes a bunch of related old FIXMEs.
2024-05-06 22:38:43 +02:00
}
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generate_yield(generator,
Bytecode::Label { continuation_block },
current_value,
received_completion,
received_completion_type,
received_completion_value,
AwaitBeforeYield::No);
}
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
// b. Else if received.[[Type]] is throw, then
generator.switch_to_basic_block(is_type_throw_block);
auto& type_is_throw_block = generator.make_block();
auto& type_is_return_block = generator.make_block();
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto received_completion_type_register_is_throw = generator.allocate_register();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::StrictlyEquals>(
received_completion_type_register_is_throw,
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
received_completion_type,
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.add_constant(Value(to_underlying(Completion::Type::Throw))));
LibJS/Bytecode: Do basic compare-and-jump peephole optimization We now fuse sequences like [LessThan, JumpIf] to JumpLessThan. This is only allowed for temporaries (i.e VM registers) with no other references to them.
2024-05-09 15:13:31 +02:00
generator.emit_jump_if(
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
received_completion_type_register_is_throw,
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
Bytecode::Label { type_is_throw_block },
Bytecode::Label { type_is_return_block });
generator.switch_to_basic_block(type_is_throw_block);
// i. Let throw be ? GetMethod(iterator, "throw").
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto throw_method = generator.allocate_register();
LibJS: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
generator.emit<Bytecode::Op::GetMethod>(throw_method, iterator, generator.intern_property_key("throw"_utf16_fly_string));
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
// ii. If throw is not undefined, then
auto& throw_method_is_defined_block = generator.make_block();
auto& throw_method_is_undefined_block = generator.make_block();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::JumpUndefined>(
throw_method,
Bytecode::Label { throw_method_is_undefined_block },
Bytecode::Label { throw_method_is_defined_block });
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
generator.switch_to_basic_block(throw_method_is_defined_block);
// 1. Let innerResult be ? Call(throw, iterator, « received.[[Value]] »).
LibJS: Avoid unnecessary `NewArray` in yield* iterator method calls Use `Op::Call` directly instead of creating a single-element array and using `CallWithArgumentArray` when calling iterator methods (`next`, `throw`, `return`) in `yield*` expressions.
2025-12-28 17:48:01 +01:00
generator.emit_with_extra_operand_slots<Bytecode::Op::Call>(1, inner_result, throw_method, iterator, OptionalNone {}, ReadonlySpan<ScopedOperand> { &received_completion_value, 1 });
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
LibJS/Bytecode: Implement async generators
2023-07-14 21:57:49 +01:00
// 2. If generatorKind is async, set innerResult to ? Await(innerResult).
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
if (generator.is_in_async_generator_function()) {
LibJS: Make async functions & generators faster with helper types Instead of returning internal generator results as ordinary JS::Objects with properties, we now use GeneratorResult and CompletionCell which both inherit from Cell directly and allow efficient access to state. 1.59x speedup on JetStream3/lazy-collections.js :^)
2025-03-31 09:32:39 +01:00
auto new_result = generate_await(generator, inner_result, received_completion, received_completion_type, received_completion_value);
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(inner_result, new_result);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
}
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
// 3. NOTE: Exceptions from the inner iterator throw method are propagated. Normal completions from an inner throw method are processed similarly to an inner next.
// 4. If innerResult is not an Object, throw a TypeError exception.
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::ThrowIfNotObject>(inner_result);
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
// 5. Let done be ? IteratorComplete(innerResult).
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit_iterator_complete(done, inner_result);
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
// 6. If done is true, then
auto& type_is_throw_done_block = generator.make_block();
auto& type_is_throw_not_done_block = generator.make_block();
LibJS/Bytecode: Do basic compare-and-jump peephole optimization We now fuse sequences like [LessThan, JumpIf] to JumpLessThan. This is only allowed for temporaries (i.e VM registers) with no other references to them.
2024-05-09 15:13:31 +02:00
generator.emit_jump_if(
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
done,
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
Bytecode::Label { type_is_throw_done_block },
Bytecode::Label { type_is_throw_not_done_block });
generator.switch_to_basic_block(type_is_throw_done_block);
// a. Return ? IteratorValue(innerResult).
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit_iterator_value(return_value, inner_result);
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { loop_end_block });
generator.switch_to_basic_block(type_is_throw_not_done_block);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
{
// 7. If generatorKind is async, set received to Completion(AsyncGeneratorYield(? IteratorValue(innerResult))).
// 8. Else, set received to Completion(GeneratorYield(innerResult)).
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
// FIXME: Yield currently only accepts a Value, not an object conforming to the IteratorResult interface, so we have to do an observable lookup of `value` here.
// This only matters for non-async generators.
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto yield_value = generator.allocate_register();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit_iterator_value(yield_value, inner_result);
LibJS: Make async functions & generators faster with helper types Instead of returning internal generator results as ordinary JS::Objects with properties, we now use GeneratorResult and CompletionCell which both inherit from Cell directly and allow efficient access to state. 1.59x speedup on JetStream3/lazy-collections.js :^)
2025-03-31 09:32:39 +01:00
generate_yield(generator, Bytecode::Label { continuation_block }, yield_value, received_completion, received_completion_type, received_completion_value, AwaitBeforeYield::No);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
}
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
generator.switch_to_basic_block(throw_method_is_undefined_block);
// 1. NOTE: If iterator does not have a throw method, this throw is going to terminate the yield* loop. But first we need to give iterator a chance to clean up.
// 2. Let closeCompletion be Completion Record { [[Type]]: normal, [[Value]]: empty, [[Target]]: empty }.
LibJS/Bytecode: Implement async generators
2023-07-14 21:57:49 +01:00
// 3. If generatorKind is async, perform ? AsyncIteratorClose(iteratorRecord, closeCompletion).
if (generator.is_in_async_generator_function()) {
LibJS: Inline AsyncIteratorClose with proper Await in for-await-of The AsyncIteratorClose bytecode op calls async_iterator_close() which uses synchronous await() internally. This spins the event loop while execution contexts are on the stack, violating the microtask checkpoint assertion in LibWeb. Replace AsyncIteratorClose op emissions in for-await-of close handlers with inline bytecode that uses the proper Await op, allowing the async function to yield and resume naturally through the event loop. For the non-throw path (break/return/continue-to-outer): emit GetMethod, Call, Await, and ThrowIfNotObject inline. For the throw path: wrap the close steps in an exception handler so that any error from GetMethod/Call/Await is discarded and the original exception is rethrown, per spec step 5.
2026-02-12 01:29:28 +01:00
// Inline AsyncIteratorClose with proper Await op to avoid
// spinning the event loop synchronously.
auto return_method = generator.allocate_register();
generator.emit<Bytecode::Op::GetMethod>(return_method, iterator, generator.intern_property_key("return"_utf16_fly_string));
auto& call_return_block = generator.make_block();
auto& after_close = generator.make_block();
generator.emit<Bytecode::Op::JumpUndefined>(return_method, Bytecode::Label { after_close }, Bytecode::Label { call_return_block });
generator.switch_to_basic_block(call_return_block);
auto inner_result = generator.allocate_register();
generator.emit_with_extra_operand_slots<Bytecode::Op::Call>(0, inner_result, return_method, iterator, OptionalNone {}, ReadonlySpan<ScopedOperand> {});
auto awaited = generate_await(generator, inner_result, received_completion, received_completion_type, received_completion_value);
generator.emit<Bytecode::Op::ThrowIfNotObject>(awaited);
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { after_close });
generator.switch_to_basic_block(after_close);
LibJS/Bytecode: Implement async generators
2023-07-14 21:57:49 +01:00
}
// 4. Else, perform ? IteratorClose(iteratorRecord, closeCompletion).
else {
LibJS: Make IteratorClose/AsyncIteratorClose take Operand for value Change the completion_value field from Optional<Value> to Operand in both IteratorClose and AsyncIteratorClose bytecode instructions. This allows passing a dynamic value from a register, which is needed for iterator close on abrupt completion where the exception value is not known at codegen time.
2026-02-11 23:49:20 +01:00
generator.emit<Bytecode::Op::IteratorClose>(iterator, next_method, done, Completion::Type::Normal, generator.add_constant(js_undefined()));
LibJS/Bytecode: Implement async generators
2023-07-14 21:57:49 +01:00
}
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
// 5. NOTE: The next step throws a TypeError to indicate that there was a yield* protocol violation: iterator does not have a throw method.
// 6. Throw a TypeError exception.
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto exception = generator.allocate_register();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::NewTypeError>(exception, generator.intern_string(ErrorType::YieldFromIteratorMissingThrowMethod.message()));
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
generator.perform_needed_unwinds<Bytecode::Op::Throw>();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::Throw>(exception);
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
// c. Else,
// i. Assert: received.[[Type]] is return.
generator.switch_to_basic_block(type_is_return_block);
// ii. Let return be ? GetMethod(iterator, "return").
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto return_method = generator.allocate_register();
LibJS: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
generator.emit<Bytecode::Op::GetMethod>(return_method, iterator, generator.intern_property_key("return"_utf16_fly_string));
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
// iii. If return is undefined, then
auto& return_is_undefined_block = generator.make_block();
auto& return_is_defined_block = generator.make_block();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::JumpUndefined>(
return_method,
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
Bytecode::Label { return_is_undefined_block },
Bytecode::Label { return_is_defined_block });
generator.switch_to_basic_block(return_is_undefined_block);
LibJS/Bytecode: Implement async generators
2023-07-14 21:57:49 +01:00
// 1. If generatorKind is async, set received.[[Value]] to ? Await(received.[[Value]]).
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
if (generator.is_in_async_generator_function()) {
LibJS: Make async functions & generators faster with helper types Instead of returning internal generator results as ordinary JS::Objects with properties, we now use GeneratorResult and CompletionCell which both inherit from Cell directly and allow efficient access to state. 1.59x speedup on JetStream3/lazy-collections.js :^)
2025-03-31 09:32:39 +01:00
generate_await(generator, received_completion_value, received_completion, received_completion_type, received_completion_value);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
}
LibJS/Bytecode: Implement async generators
2023-07-14 21:57:49 +01:00
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
// 2. Return ? received.
// NOTE: This will always be a return completion.
LibJS: Make return control flow more static With this only `ContinuePendingUnwind` needs to dynamically check if a scheduled return needs to go through a `finally` block, making the interpreter loop a bit nicer
2024-05-12 11:03:26 +02:00
generator.emit_return<Bytecode::Op::Yield>(received_completion_value);
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
generator.switch_to_basic_block(return_is_defined_block);
// iv. Let innerReturnResult be ? Call(return, iterator, « received.[[Value]] »).
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto inner_return_result = generator.allocate_register();
LibJS: Avoid unnecessary `NewArray` in yield* iterator method calls Use `Op::Call` directly instead of creating a single-element array and using `CallWithArgumentArray` when calling iterator methods (`next`, `throw`, `return`) in `yield*` expressions.
2025-12-28 17:48:01 +01:00
generator.emit_with_extra_operand_slots<Bytecode::Op::Call>(1, inner_return_result, return_method, iterator, OptionalNone {}, ReadonlySpan<ScopedOperand> { &received_completion_value, 1 });
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
LibJS/Bytecode: Implement async generators
2023-07-14 21:57:49 +01:00
// v. If generatorKind is async, set innerReturnResult to ? Await(innerReturnResult).
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
if (generator.is_in_async_generator_function()) {
LibJS: Make async functions & generators faster with helper types Instead of returning internal generator results as ordinary JS::Objects with properties, we now use GeneratorResult and CompletionCell which both inherit from Cell directly and allow efficient access to state. 1.59x speedup on JetStream3/lazy-collections.js :^)
2025-03-31 09:32:39 +01:00
auto new_value = generate_await(generator, inner_return_result, received_completion, received_completion_type, received_completion_value);
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(inner_return_result, new_value);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
}
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
// vi. If innerReturnResult is not an Object, throw a TypeError exception.
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::ThrowIfNotObject>(inner_return_result);
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
// vii. Let done be ? IteratorComplete(innerReturnResult).
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit_iterator_complete(done, inner_return_result);
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
// viii. If done is true, then
auto& type_is_return_done_block = generator.make_block();
auto& type_is_return_not_done_block = generator.make_block();
LibJS/Bytecode: Do basic compare-and-jump peephole optimization We now fuse sequences like [LessThan, JumpIf] to JumpLessThan. This is only allowed for temporaries (i.e VM registers) with no other references to them.
2024-05-09 15:13:31 +02:00
generator.emit_jump_if(
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
done,
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
Bytecode::Label { type_is_return_done_block },
Bytecode::Label { type_is_return_not_done_block });
generator.switch_to_basic_block(type_is_return_done_block);
// 1. Let value be ? IteratorValue(innerReturnResult).
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto inner_return_result_value = generator.allocate_register();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit_iterator_value(inner_return_result_value, inner_return_result);
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
// 2. Return Completion Record { [[Type]]: return, [[Value]]: value, [[Target]]: empty }.
LibJS: Make return control flow more static With this only `ContinuePendingUnwind` needs to dynamically check if a scheduled return needs to go through a `finally` block, making the interpreter loop a bit nicer
2024-05-12 11:03:26 +02:00
generator.emit_return<Bytecode::Op::Yield>(inner_return_result_value);
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
generator.switch_to_basic_block(type_is_return_not_done_block);
LibJS/Bytecode: Implement async generators
2023-07-14 21:57:49 +01:00
// ix. If generatorKind is async, set received to Completion(AsyncGeneratorYield(? IteratorValue(innerReturnResult))).
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
// x. Else, set received to Completion(GeneratorYield(innerReturnResult)).
// FIXME: Yield currently only accepts a Value, not an object conforming to the IteratorResult interface, so we have to do an observable lookup of `value` here.
LibJS/Bytecode: Implement async generators
2023-07-14 21:57:49 +01:00
// This only matters for non-async generators.
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto received = generator.allocate_register();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit_iterator_value(received, inner_return_result);
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
LibJS: Make async functions & generators faster with helper types Instead of returning internal generator results as ordinary JS::Objects with properties, we now use GeneratorResult and CompletionCell which both inherit from Cell directly and allow efficient access to state. 1.59x speedup on JetStream3/lazy-collections.js :^)
2025-03-31 09:32:39 +01:00
generate_yield(generator, Bytecode::Label { continuation_block }, received, received_completion, received_completion_type, received_completion_value, AwaitBeforeYield::No);
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
generator.switch_to_basic_block(continuation_block);
LibJS: Save and restore exceptions on yields in finalizers Also removes a bunch of related old FIXMEs.
2024-05-06 22:38:43 +02:00
if (is_in_finalizer)
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(Bytecode::Operand(Bytecode::Register::exception()), Bytecode::Operand(*saved_exception));
LibJS: Save and restore exceptions on yields in finalizers Also removes a bunch of related old FIXMEs.
2024-05-06 22:38:43 +02:00
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(received_completion, generator.accumulator());
LibJS: Make async functions & generators faster with helper types Instead of returning internal generator results as ordinary JS::Objects with properties, we now use GeneratorResult and CompletionCell which both inherit from Cell directly and allow efficient access to state. 1.59x speedup on JetStream3/lazy-collections.js :^)
2025-03-31 09:32:39 +01:00
get_received_completion_type_and_value(generator, received_completion, received_completion_type, received_completion_value);
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { loop_block });
generator.switch_to_basic_block(loop_end_block);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return return_value;
LibJS: Make ASTNode::generate_bytecode() fallible Instead of crashing on the spot, return a descriptive error that will eventually continue its days as a javascript "InternalError" exception. This should make random crashes with BC less likely.
2022-02-12 19:54:08 +03:30
}
LibJS: Correctly parse yield-from expressions This commit implements parsing for `yield *expr`, and the multiple ways something can or can't be parsed like that. Also makes yield-from a TODO in the bytecode generator. Behold, the glory of javascript syntax: ```js // 'yield' = expression in generators. function* foo() { yield *bar; // <- Syntax error here, expression can't start with * } // 'yield' = identifier anywhere else. function foo() { yield *bar; // Perfectly fine, this is just `yield * bar` } ```
2021-06-14 15:46:41 +04:30
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
Optional<ScopedOperand> argument;
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
if (m_argument)
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
argument = m_argument->generate_bytecode(generator).value();
LibJS/Bytecode: Make `yield` by itself yield undefined
2022-11-25 23:14:27 +00:00
else
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
argument = generator.add_constant(js_undefined());
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
auto& continuation_block = generator.make_block();
LibJS: Save and restore exceptions on yields in finalizers Also removes a bunch of related old FIXMEs.
2024-05-06 22:38:43 +02:00
if (is_in_finalizer) {
saved_exception = generator.allocate_register();
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(Bytecode::Operand(*saved_exception), Bytecode::Operand(Bytecode::Register::exception()));
LibJS: Save and restore exceptions on yields in finalizers Also removes a bunch of related old FIXMEs.
2024-05-06 22:38:43 +02:00
}
LibJS: Make async functions & generators faster with helper types Instead of returning internal generator results as ordinary JS::Objects with properties, we now use GeneratorResult and CompletionCell which both inherit from Cell directly and allow efficient access to state. 1.59x speedup on JetStream3/lazy-collections.js :^)
2025-03-31 09:32:39 +01:00
generate_yield(generator, Bytecode::Label { continuation_block }, *argument, received_completion, received_completion_type, received_completion_value, AwaitBeforeYield::Yes);
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
generator.switch_to_basic_block(continuation_block);
LibJS: Save and restore exceptions on yields in finalizers Also removes a bunch of related old FIXMEs.
2024-05-06 22:38:43 +02:00
if (is_in_finalizer)
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(Bytecode::Operand(Bytecode::Register::exception()), Bytecode::Operand(*saved_exception));
LibJS: Save and restore exceptions on yields in finalizers Also removes a bunch of related old FIXMEs.
2024-05-06 22:38:43 +02:00
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(received_completion, generator.accumulator());
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
LibJS: Make async functions & generators faster with helper types Instead of returning internal generator results as ordinary JS::Objects with properties, we now use GeneratorResult and CompletionCell which both inherit from Cell directly and allow efficient access to state. 1.59x speedup on JetStream3/lazy-collections.js :^)
2025-03-31 09:32:39 +01:00
get_received_completion_type_and_value(generator, received_completion, received_completion_type, received_completion_value);
LibJS: Perform received abrupt generator completions in the generator Previously, throw and return completions would not be executed inside the generator. This is incorrect, as throw and return need to perform unwinds which can potentially execute more code inside the generator, such as finally blocks. This is done by also passing the completion type alongside the passed in value. The continuation block will immediately extract and type and value and perform the appropriate operation for the given type. For normal completions, this is continuing as normal. For throw completions, it will perform `throw <value>`. For return completions, it will perform `return <value>`, which is a `Yield return` in this case due to being inside a generator. This also refactors GeneratorObject to properly send across the completion type and value to the generator inside of trying to operate on the completions itself. This is a prerequisite for yield*, as it performs special iterator operations when receiving a throw/return completion and does not complete the generator like the regular yield would. There's still more work to be done to make GeneratorObject::execute be closer to the spec. It's mostly a restructuring of the existing GeneratorObject::next_impl.
2022-11-25 23:14:08 +00:00
auto& normal_completion_continuation_block = generator.make_block();
auto& throw_completion_continuation_block = generator.make_block();
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto received_completion_type_is_normal = generator.allocate_register();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::StrictlyEquals>(
received_completion_type_is_normal,
received_completion_type,
generator.add_constant(Value(to_underlying(Completion::Type::Normal))));
LibJS/Bytecode: Do basic compare-and-jump peephole optimization We now fuse sequences like [LessThan, JumpIf] to JumpLessThan. This is only allowed for temporaries (i.e VM registers) with no other references to them.
2024-05-09 15:13:31 +02:00
generator.emit_jump_if(
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
received_completion_type_is_normal,
LibJS: Perform received abrupt generator completions in the generator Previously, throw and return completions would not be executed inside the generator. This is incorrect, as throw and return need to perform unwinds which can potentially execute more code inside the generator, such as finally blocks. This is done by also passing the completion type alongside the passed in value. The continuation block will immediately extract and type and value and perform the appropriate operation for the given type. For normal completions, this is continuing as normal. For throw completions, it will perform `throw <value>`. For return completions, it will perform `return <value>`, which is a `Yield return` in this case due to being inside a generator. This also refactors GeneratorObject to properly send across the completion type and value to the generator inside of trying to operate on the completions itself. This is a prerequisite for yield*, as it performs special iterator operations when receiving a throw/return completion and does not complete the generator like the regular yield would. There's still more work to be done to make GeneratorObject::execute be closer to the spec. It's mostly a restructuring of the existing GeneratorObject::next_impl.
2022-11-25 23:14:08 +00:00
Bytecode::Label { normal_completion_continuation_block },
Bytecode::Label { throw_completion_continuation_block });
auto& throw_value_block = generator.make_block();
auto& return_value_block = generator.make_block();
generator.switch_to_basic_block(throw_completion_continuation_block);
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto received_completion_type_is_throw = generator.allocate_register();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::StrictlyEquals>(
received_completion_type_is_throw,
received_completion_type,
generator.add_constant(Value(to_underlying(Completion::Type::Throw))));
LibJS: Perform received abrupt generator completions in the generator Previously, throw and return completions would not be executed inside the generator. This is incorrect, as throw and return need to perform unwinds which can potentially execute more code inside the generator, such as finally blocks. This is done by also passing the completion type alongside the passed in value. The continuation block will immediately extract and type and value and perform the appropriate operation for the given type. For normal completions, this is continuing as normal. For throw completions, it will perform `throw <value>`. For return completions, it will perform `return <value>`, which is a `Yield return` in this case due to being inside a generator. This also refactors GeneratorObject to properly send across the completion type and value to the generator inside of trying to operate on the completions itself. This is a prerequisite for yield*, as it performs special iterator operations when receiving a throw/return completion and does not complete the generator like the regular yield would. There's still more work to be done to make GeneratorObject::execute be closer to the spec. It's mostly a restructuring of the existing GeneratorObject::next_impl.
2022-11-25 23:14:08 +00:00
// If type is not equal to "throw" or "normal", assume it's "return".
LibJS/Bytecode: Do basic compare-and-jump peephole optimization We now fuse sequences like [LessThan, JumpIf] to JumpLessThan. This is only allowed for temporaries (i.e VM registers) with no other references to them.
2024-05-09 15:13:31 +02:00
generator.emit_jump_if(
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
received_completion_type_is_throw,
LibJS: Perform received abrupt generator completions in the generator Previously, throw and return completions would not be executed inside the generator. This is incorrect, as throw and return need to perform unwinds which can potentially execute more code inside the generator, such as finally blocks. This is done by also passing the completion type alongside the passed in value. The continuation block will immediately extract and type and value and perform the appropriate operation for the given type. For normal completions, this is continuing as normal. For throw completions, it will perform `throw <value>`. For return completions, it will perform `return <value>`, which is a `Yield return` in this case due to being inside a generator. This also refactors GeneratorObject to properly send across the completion type and value to the generator inside of trying to operate on the completions itself. This is a prerequisite for yield*, as it performs special iterator operations when receiving a throw/return completion and does not complete the generator like the regular yield would. There's still more work to be done to make GeneratorObject::execute be closer to the spec. It's mostly a restructuring of the existing GeneratorObject::next_impl.
2022-11-25 23:14:08 +00:00
Bytecode::Label { throw_value_block },
Bytecode::Label { return_value_block });
generator.switch_to_basic_block(throw_value_block);
generator.perform_needed_unwinds<Bytecode::Op::Throw>();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::Throw>(received_completion_value);
LibJS: Perform received abrupt generator completions in the generator Previously, throw and return completions would not be executed inside the generator. This is incorrect, as throw and return need to perform unwinds which can potentially execute more code inside the generator, such as finally blocks. This is done by also passing the completion type alongside the passed in value. The continuation block will immediately extract and type and value and perform the appropriate operation for the given type. For normal completions, this is continuing as normal. For throw completions, it will perform `throw <value>`. For return completions, it will perform `return <value>`, which is a `Yield return` in this case due to being inside a generator. This also refactors GeneratorObject to properly send across the completion type and value to the generator inside of trying to operate on the completions itself. This is a prerequisite for yield*, as it performs special iterator operations when receiving a throw/return completion and does not complete the generator like the regular yield would. There's still more work to be done to make GeneratorObject::execute be closer to the spec. It's mostly a restructuring of the existing GeneratorObject::next_impl.
2022-11-25 23:14:08 +00:00
generator.switch_to_basic_block(return_value_block);
LibJS: Make return control flow more static With this only `ContinuePendingUnwind` needs to dynamically check if a scheduled return needs to go through a `finally` block, making the interpreter loop a bit nicer
2024-05-12 11:03:26 +02:00
generator.emit_return<Bytecode::Op::Yield>(received_completion_value);
LibJS: Perform received abrupt generator completions in the generator Previously, throw and return completions would not be executed inside the generator. This is incorrect, as throw and return need to perform unwinds which can potentially execute more code inside the generator, such as finally blocks. This is done by also passing the completion type alongside the passed in value. The continuation block will immediately extract and type and value and perform the appropriate operation for the given type. For normal completions, this is continuing as normal. For throw completions, it will perform `throw <value>`. For return completions, it will perform `return <value>`, which is a `Yield return` in this case due to being inside a generator. This also refactors GeneratorObject to properly send across the completion type and value to the generator inside of trying to operate on the completions itself. This is a prerequisite for yield*, as it performs special iterator operations when receiving a throw/return completion and does not complete the generator like the regular yield would. There's still more work to be done to make GeneratorObject::execute be closer to the spec. It's mostly a restructuring of the existing GeneratorObject::next_impl.
2022-11-25 23:14:08 +00:00
generator.switch_to_basic_block(normal_completion_continuation_block);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return received_completion_value;
LibJS: Compile ScriptFunctions into bytecode and run them that way :^) If there's a current Bytecode::Interpreter in action, ScriptFunction will now compile itself into bytecode and execute in that context. This patch also adds the Return bytecode instruction so that we can actually return values from called functions. :^) Return values are propagated from callee to caller via the caller's $0 register. Bytecode::Interpreter now keeps a stack of register "windows". These are not very efficient, but it should be pretty straightforward to convert them to e.g a sliding register window architecture later on. This is pretty dang cool! :^)
2021-06-05 15:53:36 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> IfStatement::generate_bytecode(Bytecode::Generator& generator, Optional<ScopedOperand> preferred_dst) const
LibJS: Add basic "if" statement support to the bytecode VM :^) This also required making Bytecode::Op::Jump support lazy linking to a target label. I left a FIXME here about having the "if" statement return the result value from the taken branch statement. That's what the AST interpreter does but I'm not sure if it's actually required.
2021-06-06 13:26:50 +02:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
// test
// jump if_true (true) true (false) false
// true
// jump always (true) end
// false
// jump always (true) end
// end
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto predicate = m_predicate->generate_bytecode(generator).value();
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
LibJS/Bytecode: Don't bother propagating completion values in functions The last completion value in a function is not exposed to the language, since functions always either return something, or undefined. Given this, we can avoid emitting code that propagates the completion value from various statements, as long as we know we're generating code for a context where the completion value is not accessible. In practical terms, this means that function code gets to do less completion shuffling, while global and eval code has to keep doing it.
2024-05-14 10:57:06 +02:00
Optional<ScopedOperand> completion;
if (generator.must_propagate_completion()) {
completion = choose_dst(generator, preferred_dst);
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(*completion, generator.add_constant(js_undefined()));
LibJS/Bytecode: Don't bother propagating completion values in functions The last completion value in a function is not exposed to the language, since functions always either return something, or undefined. Given this, we can avoid emitting code that propagates the completion value from various statements, as long as we know we're generating code for a context where the completion value is not accessible. In practical terms, this means that function code gets to do less completion shuffling, while global and eval code has to keep doing it.
2024-05-14 10:57:06 +02:00
}
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto build_block = [&](auto node, Optional<BasicBlock&> end_block = {}) -> Optional<ScopedOperand> {
LibJS: Fix UpdateEmpty completion value semantics for loops/switch/if When a loop or switch body produces an abrupt completion (break or continue) with an empty value, the ES spec requires UpdateEmpty to replace the empty value with the last non-empty completion value V. The bytecode compiler was failing to do this because it only updated the completion register after body codegen, guarded by !is_current_block_terminated(). When break/continue terminated the block, the update was skipped. Fix this with three changes: 1. Introduce a CompletionRegisterScope that tells ScopeNode::generate_bytecode to eagerly emit Mov instructions into the completion register after each value-producing statement. This ensures the register is up to date before any break or continue fires. 2. Give IfStatement its own CompletionRegisterScope (initialized to undefined) during branch evaluation. This models the spec's UpdateEmpty(stmtCompletion, undefined) for if-statements: when break/continue fires inside an if-branch, the scoped jump propagation sees that the if's completion register differs from the loop's and emits a Mov, correctly replacing the eagerly written value with undefined. Without this, code like { 3; if (true) { break; } else { } } would incorrectly carry the value 3 instead of undefined through the break. 3. Capture loop body results and emit a fallback Mov for non-ScopeNode bodies (e.g. bare expression statements like do x=1; while(false)) that don't participate in the eager CompletionRegisterScope update mechanism. For labelled break/continue that cross loop boundaries, the jump codegen now propagates the inner completion register to the target scope's completion register before emitting the jump. Also fix ForStatement to use a proper completion register (previously it returned the body result directly, which was wrong for empty bodies and break-with-no-value cases).
2026-02-10 23:25:24 +01:00
Optional<Bytecode::Generator::CompletionRegisterScope> completion_scope;
if (completion.has_value())
completion_scope.emplace(generator, *completion);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto value = node->generate_bytecode(generator, completion);
LibJS: Dead code elimination for always truthy/falsey conditions This improves and expands the ability to do dead code elimination on conditions which are always truthy or falsey. The following cases are now optimized: * `if (true){}` -> Only emit `if` block, ignore `else` * `if (false){}` -> Only emit `else if`/`else` block * `while (false){}` -> Ignore `while` loop entirely * `for (x;false;){}` -> Only emit `x` (if it exists), skip `for` block * Ternary -> Directly return left/right hand side if condition is const
2026-01-25 10:57:43 -08:00
if (!generator.is_current_block_terminated()) {
if (generator.must_propagate_completion() && value.has_value())
generator.emit_mov(*completion, *value);
if (end_block.has_value())
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { *end_block });
}
return Optional<ScopedOperand> {};
};
// OPTIMIZATION: if the predicate is always true/false, only build the consequent/alternate blocks, respectively.
if (auto constant = generator.try_get_constant(predicate); constant.has_value()) {
if (constant->to_boolean_slow_case()) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
(void)build_block(m_consequent);
LibJS: Dead code elimination for always truthy/falsey conditions This improves and expands the ability to do dead code elimination on conditions which are always truthy or falsey. The following cases are now optimized: * `if (true){}` -> Only emit `if` block, ignore `else` * `if (false){}` -> Only emit `else if`/`else` block * `while (false){}` -> Ignore `while` loop entirely * `for (x;false;){}` -> Only emit `x` (if it exists), skip `for` block * Ternary -> Directly return left/right hand side if condition is const
2026-01-25 10:57:43 -08:00
} else if (m_alternate) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
(void)build_block(m_alternate);
LibJS: Dead code elimination for always truthy/falsey conditions This improves and expands the ability to do dead code elimination on conditions which are always truthy or falsey. The following cases are now optimized: * `if (true){}` -> Only emit `if` block, ignore `else` * `if (false){}` -> Only emit `else if`/`else` block * `while (false){}` -> Ignore `while` loop entirely * `for (x;false;){}` -> Only emit `x` (if it exists), skip `for` block * Ternary -> Directly return left/right hand side if condition is const
2026-01-25 10:57:43 -08:00
}
return completion;
}
auto& true_block = generator.make_block();
auto& false_block = generator.make_block();
// NOTE: if there is no 'else' block the end block is the same as the false block
auto& end_block = m_alternate ? generator.make_block() : false_block;
LibJS/Bytecode: Do basic compare-and-jump peephole optimization We now fuse sequences like [LessThan, JumpIf] to JumpLessThan. This is only allowed for temporaries (i.e VM registers) with no other references to them.
2024-05-09 15:13:31 +02:00
generator.emit_jump_if(
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
predicate,
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
Bytecode::Label { true_block },
Bytecode::Label { false_block });
generator.switch_to_basic_block(true_block);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
(void)build_block(m_consequent, { end_block });
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
if (m_alternate) {
LibJS: Don't generate useless jumps for if statement If statements without an else clause generated jumps to the next instruction, this commit fixes the if statement generation so that it dosen't produce them anymore. This is an example of JS code that generates the useless jumps (a => if(a){}) ();
2024-10-26 15:18:47 +02:00
generator.switch_to_basic_block(false_block);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
(void)build_block(m_alternate, { end_block });
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
}
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
LibJS: Let if yield undefined for branches that don't yield a value According to 13.6.7 the return value for if expressions should be undefined when the branch statements don't yield a value.
2021-06-20 12:38:59 +02:00
generator.switch_to_basic_block(end_block);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
LibJS/Bytecode: Don't bother propagating completion values in functions The last completion value in a function is not exposed to the language, since functions always either return something, or undefined. Given this, we can avoid emitting code that propagates the completion value from various statements, as long as we know we're generating code for a context where the completion value is not accessible. In practical terms, this means that function code gets to do less completion shuffling, while global and eval code has to keep doing it.
2024-05-14 10:57:06 +02:00
return completion;
LibJS: Add basic "if" statement support to the bytecode VM :^) This also required making Bytecode::Op::Jump support lazy linking to a target label. I left a FIXME here about having the "if" statement return the result value from the taken branch statement. That's what the AST interpreter does but I'm not sure if it's actually required.
2021-06-06 13:26:50 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> ContinueStatement::generate_bytecode(Bytecode::Generator& generator, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS: Add basic support for "continue" in the bytecode VM Unlike the convoluted unwind-until-scope-type mechanism in the AST interpreter, "continue" maps to a simple Bytecode::Op::Jump here. :^) We know where to jump based on a stack of "continuable scopes" that we now maintain on the Bytecode::Generator as we go. Note that this only supports bare "continue", not continue-with-label.
2021-06-06 13:33:02 +02:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS: Don't use null DFS for break/continue statements without a label
2024-01-24 13:32:02 -05:00
if (!m_target_label.has_value()) {
LibJS: Generate unwind chains for continue in Bytecode This works similar to `break` The `try-finally-continue` still do not pass with this, likely because of binding issues.
2022-11-25 16:35:39 +01:00
generator.generate_continue();
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
return Optional<ScopedOperand> {};
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
}
LibJS: Don't use null DFS for break/continue statements without a label
2024-01-24 13:32:02 -05:00
generator.generate_continue(m_target_label.value());
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
return Optional<ScopedOperand> {};
LibJS: Add basic support for "continue" in the bytecode VM Unlike the convoluted unwind-until-scope-type mechanism in the AST interpreter, "continue" maps to a simple Bytecode::Op::Jump here. :^) We know where to jump based on a stack of "continuable scopes" that we now maintain on the Bytecode::Generator as we go. Note that this only supports bare "continue", not continue-with-label.
2021-06-06 13:33:02 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> DebuggerStatement::generate_bytecode(Bytecode::Generator&, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS: Add bytecode generation for DebuggerStatement No-op. :^)
2021-06-07 20:05:50 +01:00
{
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
return Optional<ScopedOperand> {};
LibJS: Add bytecode generation for DebuggerStatement No-op. :^)
2021-06-07 20:05:50 +01:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> ConditionalExpression::generate_bytecode(Bytecode::Generator& generator, Optional<ScopedOperand> preferred_dst) const
LibJS: Add conditional expression bytecode generation Or, by its more common name, the ternary operator :^)
2021-06-08 04:54:34 +01:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS: Dead code elimination for always truthy/falsey conditions This improves and expands the ability to do dead code elimination on conditions which are always truthy or falsey. The following cases are now optimized: * `if (true){}` -> Only emit `if` block, ignore `else` * `if (false){}` -> Only emit `else if`/`else` block * `while (false){}` -> Ignore `while` loop entirely * `for (x;false;){}` -> Only emit `x` (if it exists), skip `for` block * Ternary -> Directly return left/right hand side if condition is const
2026-01-25 10:57:43 -08:00
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto test = m_test->generate_bytecode(generator).value();
LibJS: Dead code elimination for always truthy/falsey conditions This improves and expands the ability to do dead code elimination on conditions which are always truthy or falsey. The following cases are now optimized: * `if (true){}` -> Only emit `if` block, ignore `else` * `if (false){}` -> Only emit `else if`/`else` block * `while (false){}` -> Ignore `while` loop entirely * `for (x;false;){}` -> Only emit `x` (if it exists), skip `for` block * Ternary -> Directly return left/right hand side if condition is const
2026-01-25 10:57:43 -08:00
// OPTIMIZATION: if the predicate is always true/false, only build the consequent/alternate blocks, respectively.
if (auto constant = generator.try_get_constant(test); constant.has_value()) {
auto is_always_true = constant->to_boolean_slow_case();
if (is_always_true)
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
return m_consequent->generate_bytecode(generator).value();
return m_alternate->generate_bytecode(generator).value();
LibJS: Dead code elimination for always truthy/falsey conditions This improves and expands the ability to do dead code elimination on conditions which are always truthy or falsey. The following cases are now optimized: * `if (true){}` -> Only emit `if` block, ignore `else` * `if (false){}` -> Only emit `else if`/`else` block * `while (false){}` -> Ignore `while` loop entirely * `for (x;false;){}` -> Only emit `x` (if it exists), skip `for` block * Ternary -> Directly return left/right hand side if condition is const
2026-01-25 10:57:43 -08:00
}
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
// test
// jump if_true (true) true (false) false
// true
// jump always (true) end
// false
// jump always (true) end
// end
auto& true_block = generator.make_block();
auto& false_block = generator.make_block();
auto& end_block = generator.make_block();
LibJS/Bytecode: Do basic compare-and-jump peephole optimization We now fuse sequences like [LessThan, JumpIf] to JumpLessThan. This is only allowed for temporaries (i.e VM registers) with no other references to them.
2024-05-09 15:13:31 +02:00
generator.emit_jump_if(
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
test,
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
Bytecode::Label { true_block },
Bytecode::Label { false_block });
LibJS: Add conditional expression bytecode generation Or, by its more common name, the ternary operator :^)
2021-06-08 04:54:34 +01:00
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
auto dst = choose_dst(generator, preferred_dst);
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
generator.switch_to_basic_block(true_block);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto consequent = m_consequent->generate_bytecode(generator).value();
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(dst, consequent);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { end_block });
LibJS: Add conditional expression bytecode generation Or, by its more common name, the ternary operator :^)
2021-06-08 04:54:34 +01:00
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
generator.switch_to_basic_block(false_block);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto alternate = m_alternate->generate_bytecode(generator).value();
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(dst, alternate);
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { end_block });
LibJS: Add conditional expression bytecode generation Or, by its more common name, the ternary operator :^)
2021-06-08 04:54:34 +01:00
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
generator.switch_to_basic_block(end_block);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return dst;
LibJS: Add conditional expression bytecode generation Or, by its more common name, the ternary operator :^)
2021-06-08 04:54:34 +01:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> SequenceExpression::generate_bytecode(Bytecode::Generator& generator, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS: Add sequence expression bytecode generation
2021-06-08 10:13:37 +01:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
Optional<ScopedOperand> last_value;
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
for (auto& expression : m_expressions) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
last_value = expression->generate_bytecode(generator);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
}
LibJS: Make ASTNode::generate_bytecode() fallible Instead of crashing on the spot, return a descriptive error that will eventually continue its days as a javascript "InternalError" exception. This should make random crashes with BC less likely.
2022-02-12 19:54:08 +03:30
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return last_value;
LibJS: Add sequence expression bytecode generation
2021-06-08 10:13:37 +01:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> TemplateLiteral::generate_bytecode(Bytecode::Generator& generator, Optional<ScopedOperand> preferred_dst) const
LibJS: Generate bytecode for template literals
2021-06-08 19:14:01 +02:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
auto dst = choose_dst(generator, preferred_dst);
LibJS: Generate bytecode for template literals
2021-06-08 19:14:01 +02:00
LibJS: Reduce number of template literal op codes There is no need to concat empty string literals when building template literals. Now strings will only be concatenated if they need to be. To handle the edge case where the first segment is not a string literal, a new `ToString` op code has been added to ensure the value is a string concatenating more strings. In addition, basic const folding is now supported for template literal constants (templates with no interpolated values), which is commonly used for multi-line string constants.
2026-01-22 17:23:19 -08:00
Vector segments(m_expressions);
segments.remove_all_matching([&](auto expr) {
return expr->is_string_literal() && static_cast<StringLiteral const&>(*expr).value().is_empty();
});
// OPTIMIZATION: Empty template literal (``) can be turned into empty string literal ("")
if (segments.size() == 0)
return generator.add_constant(Value { GC::Ref { generator.vm().empty_string() } });
if (segments.size() == 1) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto value = segments[0]->generate_bytecode(generator).value();
LibJS: Reduce number of template literal op codes There is no need to concat empty string literals when building template literals. Now strings will only be concatenated if they need to be. To handle the edge case where the first segment is not a string literal, a new `ToString` op code has been added to ensure the value is a string concatenating more strings. In addition, basic const folding is now supported for template literal constants (templates with no interpolated values), which is commonly used for multi-line string constants.
2026-01-22 17:23:19 -08:00
// OPTIMIZATION: String literal template (`xyz`) can be returned directly
if (value.operand().is_constant())
return value;
// OPTIMIZATION: `${x}` can be turned into ToString(x) op
generator.emit<Bytecode::Op::ToString>(dst, value);
return dst;
}
for (size_t i = 0; i < segments.size(); i++) {
auto expr = segments[i];
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto value = expr->generate_bytecode(generator).value();
LibJS: Reduce number of template literal op codes There is no need to concat empty string literals when building template literals. Now strings will only be concatenated if they need to be. To handle the edge case where the first segment is not a string literal, a new `ToString` op code has been added to ensure the value is a string concatenating more strings. In addition, basic const folding is now supported for template literal constants (templates with no interpolated values), which is commonly used for multi-line string constants.
2026-01-22 17:23:19 -08:00
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
if (i == 0) {
LibJS: Reduce number of template literal op codes There is no need to concat empty string literals when building template literals. Now strings will only be concatenated if they need to be. To handle the edge case where the first segment is not a string literal, a new `ToString` op code has been added to ensure the value is a string concatenating more strings. In addition, basic const folding is now supported for template literal constants (templates with no interpolated values), which is commonly used for multi-line string constants.
2026-01-22 17:23:19 -08:00
if (expr->is_string_literal()) {
generator.emit_mov(dst, value);
} else {
generator.emit<Bytecode::Op::ToString>(dst, value);
}
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
} else {
Revert "LibJS: Remove unnecessary ConcatString bytecode instruction" This reverts commit 420187ba7c3afbd9792a3042a65978666c2de7f7. Caused 41 regressions in test262.
2025-12-10 09:17:05 -06:00
generator.emit<Bytecode::Op::ConcatString>(dst, value);
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
}
LibJS: Generate bytecode for template literals
2021-06-08 19:14:01 +02:00
}
LibJS: Fix the return value for TemplateLiteral This ensures that the bytecode generated for TemplateLiterals returns the correct value.
2021-06-09 21:11:04 +02:00
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return dst;
LibJS: Generate bytecode for template literals
2021-06-08 19:14:01 +02:00
}
LibJS: Implement bytecode generation for UpdateExpression :^) Added Increment and Decrement bytecode ops to support this. Postfix updates use a temporary register to preserve the original value. Note that this patch only implements Identifier updates. Member expression updates are a TODO.
2021-06-09 11:40:38 +02:00
LibJS: Use correct this value for tagged template literals with members Required by creepjs, which does Date().split` `[3] to get the current year.
2025-01-16 17:18:19 +00:00
struct TagAndThisValue {
ScopedOperand tag;
ScopedOperand this_value;
};
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> TaggedTemplateLiteral::generate_bytecode(Bytecode::Generator& generator, Optional<ScopedOperand> preferred_dst) const
LibJS: Generate bytecode for tagged template literals
2021-06-09 21:02:24 +02:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto [tag, this_value] = [&]() -> TagAndThisValue {
LibJS: Use correct this value for tagged template literals with members Required by creepjs, which does Date().split` `[3] to get the current year.
2025-01-16 17:18:19 +00:00
if (is<MemberExpression>(*m_tag)) {
auto& member_expression = static_cast<MemberExpression const&>(*m_tag);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto base_and_value = get_base_and_value_from_member_expression(generator, member_expression);
LibJS: Use correct this value for tagged template literals with members Required by creepjs, which does Date().split` `[3] to get the current year.
2025-01-16 17:18:19 +00:00
return TagAndThisValue { .tag = base_and_value.value, .this_value = base_and_value.base };
}
LibJS: Preserve this binding for tagged with identifiers Route tagged template identifier lookup through GetCalleeAndThisFromEnvironment only when the identifier is non-local. Keep local and global identifiers on Identifier::generate_bytecode so TDZ checks and ordinary undefined-this behavior stay intact. Expand runtime coverage with a tagged-template TDZ regression case, sequential with-binding calls, and getter-returned tag functions.
2026-02-08 18:20:26 +01:00
if (is<Identifier>(*m_tag)) {
auto& identifier = static_cast<Identifier const&>(*m_tag);
if (identifier.is_local() || identifier.is_global()) {
// Keep the normal Identifier path so local/global tags preserve
// TDZ behavior; only non-local identifiers need with-aware
// callee/this extraction.
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto tag = m_tag->generate_bytecode(generator).value();
LibJS: Preserve this binding for tagged with identifiers Route tagged template identifier lookup through GetCalleeAndThisFromEnvironment only when the identifier is non-local. Keep local and global identifiers on Identifier::generate_bytecode so TDZ checks and ordinary undefined-this behavior stay intact. Expand runtime coverage with a tagged-template TDZ regression case, sequential with-binding calls, and getter-returned tag functions.
2026-02-08 18:20:26 +01:00
return TagAndThisValue { .tag = tag, .this_value = generator.add_constant(js_undefined()) };
}
auto tag = generator.allocate_register();
auto this_value = generator.allocate_register();
generator.emit<Bytecode::Op::GetCalleeAndThisFromEnvironment>(
tag,
this_value,
generator.intern_identifier(identifier.string()));
return TagAndThisValue { .tag = tag, .this_value = this_value };
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto tag = m_tag->generate_bytecode(generator).value();
LibJS: Use correct this value for tagged template literals with members Required by creepjs, which does Date().split` `[3] to get the current year.
2025-01-16 17:18:19 +00:00
return TagAndThisValue { .tag = tag, .this_value = generator.add_constant(js_undefined()) };
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
}();
LibJS: Fix evaluation order for tagged template literals This ensures that the tag function is evaluated first.
2021-06-09 22:07:18 +02:00
LibJS: Follow the spec more closely for tagged template literals This resolves a FIXME in its code generation, particularly for: - Caching the template object - Setting the correct property attributes - Freezing the resulting objects This allows archive.org to load, which uses the Lit library. The Lit library caches these template objects to determine if a template has changed, allowing it to determine to do a full template rerender or only partially update the rendering. Before, we would always cause a full rerender on update because we didn't return the same template object. This caused issues with archive.org's code, I believe particularly with its router library, where we would constantly detach and reattach nodes unexpectedly, ending up with the page content not being attached to the router's custom element.
2026-01-06 19:49:38 +00:00
// 13.2.8.4 GetTemplateObject ( templateLiteral ), https://tc39.es/ecma262/#sec-gettemplateobject
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
Vector<ScopedOperand> string_regs;
LibJS: Generate bytecode for tagged template literals
2021-06-09 21:02:24 +02:00
auto& expressions = m_template_literal->expressions();
LibJS: Use ranges instead of specifying all registers for NewArray Listing all the registers will lead to the inability to allocate enough space in one basic block (as there can be an arbitrary number of registers used), instead switch to specifying the range of registers used and save a lot of space in the process.
2022-03-14 14:48:42 +00:00
LibJS: Follow the spec more closely for tagged template literals This resolves a FIXME in its code generation, particularly for: - Caching the template object - Setting the correct property attributes - Freezing the resulting objects This allows archive.org to load, which uses the Lit library. The Lit library caches these template objects to determine if a template has changed, allowing it to determine to do a full template rerender or only partially update the rendering. Before, we would always cause a full rerender on update because we didn't return the same template object. This caused issues with archive.org's code, I believe particularly with its router library, where we would constantly detach and reattach nodes unexpectedly, ending up with the page content not being attached to the router's custom element.
2026-01-06 19:49:38 +00:00
for (size_t i = 0; i < expressions.size(); i += 2) {
LibJS: Replace invalid escapes in TemplateLiterals with undefined in BC Also adds a big FIXME, to outline what is still wrong
2023-06-25 12:31:49 +02:00
// NOTE: If the string contains invalid escapes we get a null expression here,
// which we then convert to the expected `undefined` TV. See
// 12.9.6.1 Static Semantics: TV, https://tc39.es/ecma262/#sec-static-semantics-tv
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
if (is<NullLiteral>(expressions[i])) {
LibJS: Follow the spec more closely for tagged template literals This resolves a FIXME in its code generation, particularly for: - Caching the template object - Setting the correct property attributes - Freezing the resulting objects This allows archive.org to load, which uses the Lit library. The Lit library caches these template objects to determine if a template has changed, allowing it to determine to do a full template rerender or only partially update the rendering. Before, we would always cause a full rerender on update because we didn't return the same template object. This caused issues with archive.org's code, I believe particularly with its router library, where we would constantly detach and reattach nodes unexpectedly, ending up with the page content not being attached to the router's custom element.
2026-01-06 19:49:38 +00:00
string_regs.append(generator.add_constant(js_undefined()));
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
} else {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto value = expressions[i]->generate_bytecode(generator).value();
LibJS: Follow the spec more closely for tagged template literals This resolves a FIXME in its code generation, particularly for: - Caching the template object - Setting the correct property attributes - Freezing the resulting objects This allows archive.org to load, which uses the Lit library. The Lit library caches these template objects to determine if a template has changed, allowing it to determine to do a full template rerender or only partially update the rendering. Before, we would always cause a full rerender on update because we didn't return the same template object. This caused issues with archive.org's code, I believe particularly with its router library, where we would constantly detach and reattach nodes unexpectedly, ending up with the page content not being attached to the router's custom element.
2026-01-06 19:49:38 +00:00
string_regs.append(move(value));
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
}
LibJS: Generate bytecode for tagged template literals
2021-06-09 21:02:24 +02:00
}
LibJS: Follow the spec more closely for tagged template literals This resolves a FIXME in its code generation, particularly for: - Caching the template object - Setting the correct property attributes - Freezing the resulting objects This allows archive.org to load, which uses the Lit library. The Lit library caches these template objects to determine if a template has changed, allowing it to determine to do a full template rerender or only partially update the rendering. Before, we would always cause a full rerender on update because we didn't return the same template object. This caused issues with archive.org's code, I believe particularly with its router library, where we would constantly detach and reattach nodes unexpectedly, ending up with the page content not being attached to the router's custom element.
2026-01-06 19:49:38 +00:00
auto& raw_strings = m_template_literal->raw_strings();
for (auto const& raw_string : raw_strings) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto value = raw_string->generate_bytecode(generator).value();
LibJS: Follow the spec more closely for tagged template literals This resolves a FIXME in its code generation, particularly for: - Caching the template object - Setting the correct property attributes - Freezing the resulting objects This allows archive.org to load, which uses the Lit library. The Lit library caches these template objects to determine if a template has changed, allowing it to determine to do a full template rerender or only partially update the rendering. Before, we would always cause a full rerender on update because we didn't return the same template object. This caused issues with archive.org's code, I believe particularly with its router library, where we would constantly detach and reattach nodes unexpectedly, ending up with the page content not being attached to the router's custom element.
2026-01-06 19:49:38 +00:00
string_regs.append(move(value));
LibJS: Use ranges instead of specifying all registers for NewArray Listing all the registers will lead to the inability to allocate enough space in one basic block (as there can be an arbitrary number of registers used), instead switch to specifying the range of registers used and save a lot of space in the process.
2022-03-14 14:48:42 +00:00
}
LibJS: Generate bytecode for tagged template literals
2021-06-09 21:02:24 +02:00
LibJS: Follow the spec more closely for tagged template literals This resolves a FIXME in its code generation, particularly for: - Caching the template object - Setting the correct property attributes - Freezing the resulting objects This allows archive.org to load, which uses the Lit library. The Lit library caches these template objects to determine if a template has changed, allowing it to determine to do a full template rerender or only partially update the rendering. Before, we would always cause a full rerender on update because we didn't return the same template object. This caused issues with archive.org's code, I believe particularly with its router library, where we would constantly detach and reattach nodes unexpectedly, ending up with the page content not being attached to the router's custom element.
2026-01-06 19:49:38 +00:00
auto strings_array = generator.allocate_register();
generator.emit_with_extra_operand_slots<Bytecode::Op::GetTemplateObject>(
string_regs.size(),
strings_array,
generator.next_template_object_cache(),
string_regs);
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
Vector<ScopedOperand> argument_regs;
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
argument_regs.append(strings_array);
LibJS: Generate bytecode for tagged template literals
2021-06-09 21:02:24 +02:00
LibJS: Switch to array-calls in the bytecode vm This will make it easier to implement spreading arguments.
2022-09-07 23:39:43 +02:00
for (size_t i = 1; i < expressions.size(); i += 2) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto argument = expressions[i]->generate_bytecode(generator).value();
LibJS: Follow the spec more closely for tagged template literals This resolves a FIXME in its code generation, particularly for: - Caching the template object - Setting the correct property attributes - Freezing the resulting objects This allows archive.org to load, which uses the Lit library. The Lit library caches these template objects to determine if a template has changed, allowing it to determine to do a full template rerender or only partially update the rendering. Before, we would always cause a full rerender on update because we didn't return the same template object. This caused issues with archive.org's code, I believe particularly with its router library, where we would constantly detach and reattach nodes unexpectedly, ending up with the page content not being attached to the router's custom element.
2026-01-06 19:49:38 +00:00
argument_regs.append(move(argument));
LibJS: Generate bytecode for tagged template literals
2021-06-09 21:02:24 +02:00
}
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
auto dst = choose_dst(generator, preferred_dst);
LibJS: Follow the spec more closely for tagged template literals This resolves a FIXME in its code generation, particularly for: - Caching the template object - Setting the correct property attributes - Freezing the resulting objects This allows archive.org to load, which uses the Lit library. The Lit library caches these template objects to determine if a template has changed, allowing it to determine to do a full template rerender or only partially update the rendering. Before, we would always cause a full rerender on update because we didn't return the same template object. This caused issues with archive.org's code, I believe particularly with its router library, where we would constantly detach and reattach nodes unexpectedly, ending up with the page content not being attached to the router's custom element.
2026-01-06 19:49:38 +00:00
generator.emit_with_extra_operand_slots<Bytecode::Op::Call>(argument_regs.size(), dst, tag, this_value, OptionalNone {}, argument_regs);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return dst;
LibJS: Generate bytecode for tagged template literals
2021-06-09 21:02:24 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> UpdateExpression::generate_bytecode(Bytecode::Generator& generator, Optional<ScopedOperand>) const
LibJS: Implement bytecode generation for UpdateExpression :^) Added Increment and Decrement bytecode ops to support this. Postfix updates use a temporary register to preserve the original value. Note that this patch only implements Identifier updates. Member expression updates are a TODO.
2021-06-09 11:40:38 +02:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto reference = generator.emit_load_from_reference(*m_argument);
LibJS: Implement bytecode generation for UpdateExpression :^) Added Increment and Decrement bytecode ops to support this. Postfix updates use a temporary register to preserve the original value. Note that this patch only implements Identifier updates. Member expression updates are a TODO.
2021-06-09 11:40:38 +02:00
LibJS: Don't emit dead code after Throw for invalid LHS expressions When the left-hand side of an assignment, update, or for-in loop is invalid (e.g. `foo() = "bar"`), the bytecode generator emits a Throw instruction. Previously, it would also create a dead basic block after the Throw, resulting in unreachable instructions in the output. Fix this by returning early from the relevant codegen paths after emitting the Throw, and by guarding for-in/for-of body generation with an is_current_block_terminated() check.
2026-03-01 13:17:26 +01:00
if (!reference.loaded_value.has_value())
return {};
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
Optional<ScopedOperand> previous_value_for_postfix;
LibJS: Implement bytecode generation for UpdateExpression :^) Added Increment and Decrement bytecode ops to support this. Postfix updates use a temporary register to preserve the original value. Note that this patch only implements Identifier updates. Member expression updates are a TODO.
2021-06-09 11:40:38 +02:00
LibJS/Bytecode: Dedicated instructions for postfix increment/decrement Instead of splitting the postfix variants into ToNumeric + Inc/Dec, we now have dedicated PostfixIncrement and PostfixDecrement instructions that handle both outputs in one go.
2024-02-20 11:45:01 +01:00
if (m_op == UpdateOp::Increment) {
if (m_prefixed) {
generator.emit<Bytecode::Op::Increment>(*reference.loaded_value);
} else {
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
previous_value_for_postfix = generator.allocate_register();
LibJS/Bytecode: Dedicated instructions for postfix increment/decrement Instead of splitting the postfix variants into ToNumeric + Inc/Dec, we now have dedicated PostfixIncrement and PostfixDecrement instructions that handle both outputs in one go.
2024-02-20 11:45:01 +01:00
generator.emit<Bytecode::Op::PostfixIncrement>(*previous_value_for_postfix, *reference.loaded_value);
}
} else {
if (m_prefixed) {
generator.emit<Bytecode::Op::Decrement>(*reference.loaded_value);
} else {
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
previous_value_for_postfix = generator.allocate_register();
LibJS/Bytecode: Dedicated instructions for postfix increment/decrement Instead of splitting the postfix variants into ToNumeric + Inc/Dec, we now have dedicated PostfixIncrement and PostfixDecrement instructions that handle both outputs in one go.
2024-02-20 11:45:01 +01:00
generator.emit<Bytecode::Op::PostfixDecrement>(*previous_value_for_postfix, *reference.loaded_value);
}
}
LibJS: Implement bytecode generation for UpdateExpression :^) Added Increment and Decrement bytecode ops to support this. Postfix updates use a temporary register to preserve the original value. Note that this patch only implements Identifier updates. Member expression updates are a TODO.
2021-06-09 11:40:38 +02:00
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
if (is<Identifier>(*m_argument))
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
generator.emit_store_to_reference(static_cast<Identifier const&>(*m_argument), *reference.loaded_value);
LibJS: Don't evaluate computed MemberExpression LHS twice in assignments The following snippet would cause "i" to be incremented twice(!): let a = [] let i = 0 a[++i] += 0 This patch solves the issue by remembering the base object and property name for computed MemberExpression LHS in codegen. We the store the result of the assignment to the same object and property (instead of computing the LHS again). 3 new passes on test262. :^)
2023-10-04 15:22:07 +02:00
else
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
generator.emit_store_to_reference(reference, *reference.loaded_value);
LibJS: Implement bytecode generation for UpdateExpression :^) Added Increment and Decrement bytecode ops to support this. Postfix updates use a temporary register to preserve the original value. Note that this patch only implements Identifier updates. Member expression updates are a TODO.
2021-06-09 11:40:38 +02:00
LibJS: Generate bytecode for UpdateExpression with MemberExpression arg
2021-10-25 15:17:41 +02:00
if (!m_prefixed)
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return *previous_value_for_postfix;
return *reference.loaded_value;
LibJS: Implement bytecode generation for UpdateExpression :^) Added Increment and Decrement bytecode ops to support this. Postfix updates use a temporary register to preserve the original value. Note that this patch only implements Identifier updates. Member expression updates are a TODO.
2021-06-09 11:40:38 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> ThrowStatement::generate_bytecode(Bytecode::Generator& generator, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS: Generate bytecode for throw statements
2021-06-09 18:18:56 +02:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto argument = m_argument->generate_bytecode(generator).value();
LibJS/Bytecode: Unwind to closest unwind boundary on Throw This will leave any lexical/variable environments on the way to the closest unwind context boundary. This will not leave the closest unwind context, as we still need the unwind context to perform the Throw instruction correctly.
2022-03-14 02:26:39 +00:00
generator.perform_needed_unwinds<Bytecode::Op::Throw>();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::Throw>(argument);
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
return Optional<ScopedOperand> {};
LibJS: Generate bytecode for throw statements
2021-06-09 18:18:56 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> BreakStatement::generate_bytecode(Bytecode::Generator& generator, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS: Implement bytecode generation for BreakStatement
2021-06-10 20:28:43 +08:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS: Intercept returns through finally blocks in Bytecode This is still not perfect, as we now actually crash in the `try-finally-continue` tests, while we now succeed all `try-catch-finally-*` tests. Note that we do not yet go through the finally block when exiting the unwind context through a break or continue.
2022-11-13 20:56:53 +01:00
// FIXME: Handle finally blocks in a graceful manner
// We need to execute the finally block, but tell it to resume
// execution at the designated block
LibJS: Don't use null DFS for break/continue statements without a label
2024-01-24 13:32:02 -05:00
if (!m_target_label.has_value()) {
LibJS: Generate unwind chains for break in Bytecode This uses a newly added instruction `ScheduleJump` This instruction tells the finally proceeding it, that instead of jumping to it's next block it should jump to the designated block.
2022-11-25 16:15:34 +01:00
generator.generate_break();
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
return Optional<ScopedOperand> {};
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
}
LibJS: Don't use null DFS for break/continue statements without a label
2024-01-24 13:32:02 -05:00
generator.generate_break(m_target_label.value());
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
return Optional<ScopedOperand> {};
LibJS: Implement bytecode generation for BreakStatement
2021-06-10 20:28:43 +08:00
}
LibJS: Use explicit completion records for try/finally dispatch Each finally scope gets two registers (completion_type and completion_value) that form an explicit completion record. Every path into the finally body sets these before jumping, and a dispatch chain after the finally body routes to the correct continuation. This replaces the old implicit protocol that relied on the exception register, a saved_return_value register, and a scheduled_jump field on ExecutionContext, allowing us to remove: - 5 opcodes (ContinuePendingUnwind, ScheduleJump, LeaveFinally, RestoreScheduledJump, PrepareYield) - 1 reserved register (saved_return_value) - 2 ExecutionContext fields (scheduled_jump, previously_scheduled_jumps)
2026-02-09 01:41:19 +01:00
// Try/finally uses an explicit completion record protocol:
//
// 1. Allocate two registers: completion_type and completion_value
// 2. Every path into the finally body sets these before jumping:
// - Normal exit: completion_type = NORMAL
// - Exception: completion_type = THROW, completion_value = exception
// - Return: completion_type = RETURN, completion_value = return value
// - Break/continue: completion_type = FIRST_JUMP_INDEX + n
// 3. After the finally body, a dispatch chain checks completion_type
// and routes to the correct continuation (next block, jump target,
// return, or rethrow).
//
// For exceptions, the handler table points to an "exception preamble" block
// that catches the exception into completion_value, sets completion_type to
// THROW, and jumps to the finally body.
//
// For nested finally (e.g. break through two finally blocks), trampoline
// blocks chain through each finally layer, with each inner finally dispatching
// to a trampoline that sets up the outer finally's completion record.
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> TryStatement::generate_bytecode(Bytecode::Generator& generator, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
auto& saved_block = generator.current_block();
Optional<Bytecode::Label> handler_target;
LibJS: Create static unwind mappings for `BasicBlock`s This is currently only used in the bytecode dump to annotate to where unwinds lead per block, but will be hooked up to the virtual machine in the next commit.
2023-10-19 23:18:54 +02:00
Optional<Bytecode::Generator::UnwindContext> unwind_context;
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
Bytecode::BasicBlock* next_block { nullptr };
LibJS/Bytecode: Don't bother propagating completion values in functions The last completion value in a function is not exposed to the language, since functions always either return something, or undefined. Given this, we can avoid emitting code that propagates the completion value from various statements, as long as we know we're generating code for a context where the completion value is not accessible. In practical terms, this means that function code gets to do less completion shuffling, while global and eval code has to keep doing it.
2024-05-14 10:57:06 +02:00
Optional<ScopedOperand> completion;
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
LibJS: Use explicit completion records for try/finally dispatch Each finally scope gets two registers (completion_type and completion_value) that form an explicit completion record. Every path into the finally body sets these before jumping, and a dispatch chain after the finally body routes to the correct continuation. This replaces the old implicit protocol that relied on the exception register, a saved_return_value register, and a scheduled_jump field on ExecutionContext, allowing us to remove: - 5 opcodes (ContinuePendingUnwind, ScheduleJump, LeaveFinally, RestoreScheduledJump, PrepareYield) - 1 reserved register (saved_return_value) - 2 ExecutionContext fields (scheduled_jump, previously_scheduled_jumps)
2026-02-09 01:41:19 +01:00
Optional<Bytecode::Generator::FinallyContext> finally_context;
Bytecode::BasicBlock* finally_body_block_ptr { nullptr };
LibJS: Replace implicit environment stack with explicit registers Replace the saved_lexical_environments stack in ExecutionContextRareData with explicit register-based environment tracking. Environments are now stored in registers and restored via SetLexicalEnvironment, making the environment flow visible in bytecode. Key changes: - Add GetLexicalEnvironment and SetLexicalEnvironment opcodes - CreateLexicalEnvironment takes explicit parent and dst operands - EnterObjectEnvironment stores new environment in a dst register - NewClass takes an explicit class_environment operand - Remove LeaveLexicalEnvironment opcode (instead: SetLexicalEnvironment) - Remove saved_lexical_environments from ExecutionContextRareData - Use a reserved register for the saved lexical environment to avoid dominance issues with lazily-emitted GetLexicalEnvironment
2026-02-09 03:34:42 +01:00
// Capture the lexical environment at try entry for restoration on catch/exception.
Optional<ScopedOperand> lexical_environment_at_entry;
lexical_environment_at_entry = generator.current_lexical_environment_register();
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
if (m_finalizer) {
LibJS: Use explicit completion records for try/finally dispatch Each finally scope gets two registers (completion_type and completion_value) that form an explicit completion record. Every path into the finally body sets these before jumping, and a dispatch chain after the finally body routes to the correct continuation. This replaces the old implicit protocol that relied on the exception register, a saved_return_value register, and a scheduled_jump field on ExecutionContext, allowing us to remove: - 5 opcodes (ContinuePendingUnwind, ScheduleJump, LeaveFinally, RestoreScheduledJump, PrepareYield) - 1 reserved register (saved_return_value) - 2 ExecutionContext fields (scheduled_jump, previously_scheduled_jumps)
2026-02-09 01:41:19 +01:00
// Allocate completion record registers.
auto completion_type = generator.allocate_register();
auto completion_value = generator.allocate_register();
// Create the exception preamble block (handler table points here for exceptions).
auto& exception_preamble_block = generator.make_block();
// Create the finally body block (all paths converge here).
auto& finally_body_block = generator.make_block();
finally_body_block_ptr = &finally_body_block;
// Set up FinallyContext.
finally_context.emplace(Bytecode::Generator::FinallyContext {
.completion_type = completion_type,
.completion_value = completion_value,
.finally_body = Bytecode::Label { finally_body_block },
.exception_preamble = Bytecode::Label { exception_preamble_block },
.parent = generator.current_finally_context(),
.registered_jumps = {},
.next_jump_index = Bytecode::Generator::FinallyContext::FIRST_JUMP_INDEX,
LibJS: Replace implicit environment stack with explicit registers Replace the saved_lexical_environments stack in ExecutionContextRareData with explicit register-based environment tracking. Environments are now stored in registers and restored via SetLexicalEnvironment, making the environment flow visible in bytecode. Key changes: - Add GetLexicalEnvironment and SetLexicalEnvironment opcodes - CreateLexicalEnvironment takes explicit parent and dst operands - EnterObjectEnvironment stores new environment in a dst register - NewClass takes an explicit class_environment operand - Remove LeaveLexicalEnvironment opcode (instead: SetLexicalEnvironment) - Remove saved_lexical_environments from ExecutionContextRareData - Use a reserved register for the saved lexical environment to avoid dominance issues with lazily-emitted GetLexicalEnvironment
2026-02-09 03:34:42 +01:00
.lexical_environment_at_entry = lexical_environment_at_entry,
LibJS: Use explicit completion records for try/finally dispatch Each finally scope gets two registers (completion_type and completion_value) that form an explicit completion record. Every path into the finally body sets these before jumping, and a dispatch chain after the finally body routes to the correct continuation. This replaces the old implicit protocol that relied on the exception register, a saved_return_value register, and a scheduled_jump field on ExecutionContext, allowing us to remove: - 5 opcodes (ContinuePendingUnwind, ScheduleJump, LeaveFinally, RestoreScheduledJump, PrepareYield) - 1 reserved register (saved_return_value) - 2 ExecutionContext fields (scheduled_jump, previously_scheduled_jumps)
2026-02-09 01:41:19 +01:00
});
generator.set_current_finally_context(&*finally_context);
// Generate exception preamble:
// Catch completion_value
LibJS: Replace implicit environment stack with explicit registers Replace the saved_lexical_environments stack in ExecutionContextRareData with explicit register-based environment tracking. Environments are now stored in registers and restored via SetLexicalEnvironment, making the environment flow visible in bytecode. Key changes: - Add GetLexicalEnvironment and SetLexicalEnvironment opcodes - CreateLexicalEnvironment takes explicit parent and dst operands - EnterObjectEnvironment stores new environment in a dst register - NewClass takes an explicit class_environment operand - Remove LeaveLexicalEnvironment opcode (instead: SetLexicalEnvironment) - Remove saved_lexical_environments from ExecutionContextRareData - Use a reserved register for the saved lexical environment to avoid dominance issues with lazily-emitted GetLexicalEnvironment
2026-02-09 03:34:42 +01:00
// SetLexicalEnvironment (restore to try entry)
LibJS: Use explicit completion records for try/finally dispatch Each finally scope gets two registers (completion_type and completion_value) that form an explicit completion record. Every path into the finally body sets these before jumping, and a dispatch chain after the finally body routes to the correct continuation. This replaces the old implicit protocol that relied on the exception register, a saved_return_value register, and a scheduled_jump field on ExecutionContext, allowing us to remove: - 5 opcodes (ContinuePendingUnwind, ScheduleJump, LeaveFinally, RestoreScheduledJump, PrepareYield) - 1 reserved register (saved_return_value) - 2 ExecutionContext fields (scheduled_jump, previously_scheduled_jumps)
2026-02-09 01:41:19 +01:00
// Mov completion_type, 1 (Throw)
// Jump finally_body
generator.switch_to_basic_block(exception_preamble_block);
generator.emit<Bytecode::Op::Catch>(completion_value);
LibJS: Replace implicit environment stack with explicit registers Replace the saved_lexical_environments stack in ExecutionContextRareData with explicit register-based environment tracking. Environments are now stored in registers and restored via SetLexicalEnvironment, making the environment flow visible in bytecode. Key changes: - Add GetLexicalEnvironment and SetLexicalEnvironment opcodes - CreateLexicalEnvironment takes explicit parent and dst operands - EnterObjectEnvironment stores new environment in a dst register - NewClass takes an explicit class_environment operand - Remove LeaveLexicalEnvironment opcode (instead: SetLexicalEnvironment) - Remove saved_lexical_environments from ExecutionContextRareData - Use a reserved register for the saved lexical environment to avoid dominance issues with lazily-emitted GetLexicalEnvironment
2026-02-09 03:34:42 +01:00
generator.emit<Bytecode::Op::SetLexicalEnvironment>(*lexical_environment_at_entry);
LibJS: Use explicit completion records for try/finally dispatch Each finally scope gets two registers (completion_type and completion_value) that form an explicit completion record. Every path into the finally body sets these before jumping, and a dispatch chain after the finally body routes to the correct continuation. This replaces the old implicit protocol that relied on the exception register, a saved_return_value register, and a scheduled_jump field on ExecutionContext, allowing us to remove: - 5 opcodes (ContinuePendingUnwind, ScheduleJump, LeaveFinally, RestoreScheduledJump, PrepareYield) - 1 reserved register (saved_return_value) - 2 ExecutionContext fields (scheduled_jump, previously_scheduled_jumps)
2026-02-09 01:41:19 +01:00
generator.emit_mov(completion_type, generator.add_constant(Value(Bytecode::Generator::FinallyContext::THROW)));
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { finally_body_block });
LibJS: Cleanup unwind state when transferring control out of a finalizer This does two things: * Clear exceptions when transferring control out of a finalizer Otherwise they would resurface at the end of the next finalizer (see test the new test case), or at the end of a function * Pop one scheduled jump when transferring control out of a finalizer This removes one old FIXME
2024-04-11 11:58:18 +02:00
LibJS: Use explicit completion records for try/finally dispatch Each finally scope gets two registers (completion_type and completion_value) that form an explicit completion record. Every path into the finally body sets these before jumping, and a dispatch chain after the finally body routes to the correct continuation. This replaces the old implicit protocol that relied on the exception register, a saved_return_value register, and a scheduled_jump field on ExecutionContext, allowing us to remove: - 5 opcodes (ContinuePendingUnwind, ScheduleJump, LeaveFinally, RestoreScheduledJump, PrepareYield) - 1 reserved register (saved_return_value) - 2 ExecutionContext fields (scheduled_jump, previously_scheduled_jumps)
2026-02-09 01:41:19 +01:00
// Set up unwind context with exception_preamble as finalizer.
LibJS: Intercept returns through finally blocks in Bytecode This is still not perfect, as we now actually crash in the `try-finally-continue` tests, while we now succeed all `try-catch-finally-*` tests. Note that we do not yet go through the finally block when exiting the unwind context through a break or continue.
2022-11-13 20:56:53 +01:00
generator.start_boundary(Bytecode::Generator::BlockBoundaryType::ReturnToFinally);
LibJS: Use explicit completion records for try/finally dispatch Each finally scope gets two registers (completion_type and completion_value) that form an explicit completion record. Every path into the finally body sets these before jumping, and a dispatch chain after the finally body routes to the correct continuation. This replaces the old implicit protocol that relied on the exception register, a saved_return_value register, and a scheduled_jump field on ExecutionContext, allowing us to remove: - 5 opcodes (ContinuePendingUnwind, ScheduleJump, LeaveFinally, RestoreScheduledJump, PrepareYield) - 1 reserved register (saved_return_value) - 2 ExecutionContext fields (scheduled_jump, previously_scheduled_jumps)
2026-02-09 01:41:19 +01:00
unwind_context.emplace(generator, Bytecode::Label { exception_preamble_block });
LibJS: Create static unwind mappings for `BasicBlock`s This is currently only used in the bytecode dump to annotate to where unwinds lead per block, but will be hooked up to the virtual machine in the next commit.
2023-10-19 23:18:54 +02:00
}
LibJS: Use explicit completion records for try/finally dispatch Each finally scope gets two registers (completion_type and completion_value) that form an explicit completion record. Every path into the finally body sets these before jumping, and a dispatch chain after the finally body routes to the correct continuation. This replaces the old implicit protocol that relied on the exception register, a saved_return_value register, and a scheduled_jump field on ExecutionContext, allowing us to remove: - 5 opcodes (ContinuePendingUnwind, ScheduleJump, LeaveFinally, RestoreScheduledJump, PrepareYield) - 1 reserved register (saved_return_value) - 2 ExecutionContext fields (scheduled_jump, previously_scheduled_jumps)
2026-02-09 01:41:19 +01:00
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
if (m_handler) {
auto& handler_block = generator.make_block();
generator.switch_to_basic_block(handler_block);
LibJS: Intercept returns through finally blocks in Bytecode This is still not perfect, as we now actually crash in the `try-finally-continue` tests, while we now succeed all `try-catch-finally-*` tests. Note that we do not yet go through the finally block when exiting the unwind context through a break or continue.
2022-11-13 20:56:53 +01:00
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto caught_value = generator.allocate_register();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::Catch>(caught_value);
LibJS: Replace implicit environment stack with explicit registers Replace the saved_lexical_environments stack in ExecutionContextRareData with explicit register-based environment tracking. Environments are now stored in registers and restored via SetLexicalEnvironment, making the environment flow visible in bytecode. Key changes: - Add GetLexicalEnvironment and SetLexicalEnvironment opcodes - CreateLexicalEnvironment takes explicit parent and dst operands - EnterObjectEnvironment stores new environment in a dst register - NewClass takes an explicit class_environment operand - Remove LeaveLexicalEnvironment opcode (instead: SetLexicalEnvironment) - Remove saved_lexical_environments from ExecutionContextRareData - Use a reserved register for the saved lexical environment to avoid dominance issues with lazily-emitted GetLexicalEnvironment
2026-02-09 03:34:42 +01:00
generator.emit<Bytecode::Op::SetLexicalEnvironment>(*lexical_environment_at_entry);
LibJS/JIT: Update "unwind context" stack in JIT code Until now, the unwind context stack has not been maintained by jitted code, which meant we were unable to support the `with` statement. This is a first step towards supporting that by making jitted code call out to C++ to update the unwind context stack when entering/leaving unwind contexts. We also introduce a new "Catch" bytecode instruction that moves the current exception into the accumulator. It's always emitted at the start of a "catch" block.
2023-11-11 23:19:46 +01:00
LibJS: Avoid creating empty environment for `catch` without parameter When there is no `catch` parameter to bind the error, we don't need to allocate an environment, since there's nothing to add to it. This avoids one environment allocation every time we catch like this: try { ... } catch { ... }
2023-09-25 14:11:27 +02:00
// OPTIMIZATION: We avoid creating a lexical environment if the catch clause has no parameter.
bool did_create_variable_scope_for_catch_clause = false;
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
m_handler->parameter().visit(
[&](NonnullRefPtr<Identifier const> const& parameter) -> void {
LibJS: Allow using local variable for catch parameters Local variables are faster to access and if all catch parameters are locals we can skip lexical environment allocation.
2025-04-22 00:05:36 +02:00
if (parameter->is_local()) {
LibJS: Skip allocating locals for arguments that allowed to be local This allows us to get rid of instructions that move arguments to locals and allocate smaller JS::Value vector in ExecutionContext by reusing slots that were already allocated for arguments. With this change for following function: ```js function f(x, y) { return x + y; } ``` we now produce following bytecode: ``` [ 0] 0: Add dst:reg6, lhs:arg0, rhs:arg1 [ 10] Return value:reg6 ``` instead of: ``` [ 0] 0: GetArgument 0, dst:x~1 [ 10] GetArgument 1, dst:y~0 [ 20] Add dst:reg6, lhs:x~1, rhs:y~0 [ 30] Return value:reg6 ```
2025-04-25 17:10:47 +02:00
auto local = generator.local(parameter->local_index());
LibJS: Allow using local variable for catch parameters Local variables are faster to access and if all catch parameters are locals we can skip lexical environment allocation.
2025-04-22 00:05:36 +02:00
generator.emit_mov(local, caught_value);
LibJS: Mark `catch` parameter as initialized local when applicable Otherwise we'll emit a TDZ check for every `catch` parameter immediately after initializing it. This check would never fail, so it's redundant.
2025-04-29 16:41:31 +02:00
generator.set_local_initialized(parameter->local_index());
LibJS: Allow using local variable for catch parameters Local variables are faster to access and if all catch parameters are locals we can skip lexical environment allocation.
2025-04-22 00:05:36 +02:00
} else {
generator.begin_variable_scope();
did_create_variable_scope_for_catch_clause = true;
auto parameter_identifier = generator.intern_identifier(parameter->string());
LibJS: Generate C++ bytecode instruction classes from a definition file This commit adds a new Bytecode.def file that describes all the LibJS bytecode instructions. From this, we are able to generate the full declarations for all C++ bytecode instruction classes, as well as their serialization code. Note that some of the bytecode compiler was updated since instructions no longer have default constructor arguments. The big immediate benefit here is that we lose a couple thousand lines of hand-written C++ code. Going forward, this also allows us to do more tooling for the bytecode VM, now that we have an authoritative description of its instructions. Key things to know about: - Instructions can inherit from one another. At the moment, everything simply inherits from the base "Instruction". - @terminator means the instruction terminates a basic block. - @nothrow means the instruction cannot throw. This affects how the interpreter interacts with it. - Variable-length instructions are automatically supported. Just put an array of something as the last field of the instruction. - The m_length field is magical. If present, it will be populated with the full length of the instruction. This is used for variable-length instructions.
2025-11-20 22:14:50 +01:00
generator.emit<Bytecode::Op::CreateVariable>(parameter_identifier, Bytecode::Op::EnvironmentMode::Lexical, false, false, false);
LibJS: Allow using local variable for catch parameters Local variables are faster to access and if all catch parameters are locals we can skip lexical environment allocation.
2025-04-22 00:05:36 +02:00
generator.emit<Bytecode::Op::InitializeLexicalBinding>(parameter_identifier, caught_value);
}
LibJS: Add support for binding patterns in catch clauses `try { ... } catch({a=foo}) {}` is valid, and now we parse and evaluate it correctly :^)
2021-07-11 15:15:38 +04:30
},
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
[&](NonnullRefPtr<BindingPattern const> const& binding_pattern) -> void {
LibJS: Allow using local variable for catch parameters Local variables are faster to access and if all catch parameters are locals we can skip lexical environment allocation.
2025-04-22 00:05:36 +02:00
MUST(binding_pattern->for_each_bound_identifier([&](auto const& identifier) {
if (!identifier.is_local())
did_create_variable_scope_for_catch_clause = true;
}));
if (did_create_variable_scope_for_catch_clause)
generator.begin_variable_scope();
MUST(binding_pattern->for_each_bound_identifier([&](auto const& identifier) {
if (identifier.is_local())
return;
auto parameter_identifier = generator.intern_identifier(identifier.string());
LibJS: Generate C++ bytecode instruction classes from a definition file This commit adds a new Bytecode.def file that describes all the LibJS bytecode instructions. From this, we are able to generate the full declarations for all C++ bytecode instruction classes, as well as their serialization code. Note that some of the bytecode compiler was updated since instructions no longer have default constructor arguments. The big immediate benefit here is that we lose a couple thousand lines of hand-written C++ code. Going forward, this also allows us to do more tooling for the bytecode VM, now that we have an authoritative description of its instructions. Key things to know about: - Instructions can inherit from one another. At the moment, everything simply inherits from the base "Instruction". - @terminator means the instruction terminates a basic block. - @nothrow means the instruction cannot throw. This affects how the interpreter interacts with it. - Variable-length instructions are automatically supported. Just put an array of something as the last field of the instruction. - The m_length field is magical. If present, it will be populated with the full length of the instruction. This is used for variable-length instructions.
2025-11-20 22:14:50 +01:00
generator.emit<Bytecode::Op::CreateVariable>(parameter_identifier, Bytecode::Op::EnvironmentMode::Lexical, false, false, false);
LibJS: Allow using local variable for catch parameters Local variables are faster to access and if all catch parameters are locals we can skip lexical environment allocation.
2025-04-22 00:05:36 +02:00
}));
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
binding_pattern->generate_bytecode(generator, Bytecode::Op::BindingInitializationMode::Initialize, caught_value);
LibJS: Use Identifier to represent CatchClause parameter names By doing that we consistently use Identifier node for identifiers and also enable mechanism that registers identifiers in a corresponding ScopePusher for catch parameters, which is necessary for work in the upcoming changes.
2025-04-21 19:49:38 +02:00
},
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
[](Empty) -> void {
});
LibJS: Add support for binding patterns in catch clauses `try { ... } catch({a=foo}) {}` is valid, and now we parse and evaluate it correctly :^)
2021-07-11 15:15:38 +04:30
LibJS: Give try/catch/finally blocks own completion registers Each of the three blocks in a TryStatement (try body, catch body, finally body) needs its own CompletionRegisterScope so that break/continue inside any of them carries the block's own completion value rather than leaking a value from a surrounding statement or a different block. Previously, statements inside these blocks would update the enclosing scope's completion register (e.g. a for-loop's register), and if break/continue fired with no prior expression value, the enclosing register's stale value would leak through as the completion value instead of undefined. Each block now allocates a fresh register initialized to undefined and uses it as the current completion register during body generation. This matches the pattern already used by loops and switch statements.
2026-02-11 00:07:26 +01:00
Optional<ScopedOperand> catch_completion;
{
// NB: The catch body needs its own completion register so that
// break/continue inside the catch block carries the catch's
// own completion value rather than leaking a value from an
// enclosing statement.
Optional<Bytecode::Generator::CompletionRegisterScope> completion_scope;
if (generator.must_propagate_completion()) {
catch_completion = generator.allocate_register();
generator.emit_mov(*catch_completion, generator.add_constant(js_undefined()));
completion_scope.emplace(generator, *catch_completion);
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
(void)m_handler->body().generate_bytecode(generator);
LibJS: Give try/catch/finally blocks own completion registers Each of the three blocks in a TryStatement (try body, catch body, finally body) needs its own CompletionRegisterScope so that break/continue inside any of them carries the block's own completion value rather than leaking a value from a surrounding statement or a different block. Previously, statements inside these blocks would update the enclosing scope's completion register (e.g. a for-loop's register), and if break/continue fired with no prior expression value, the enclosing register's stale value would leak through as the completion value instead of undefined. Each block now allocates a fresh register initialized to undefined and uses it as the current completion register during body generation. This matches the pattern already used by loops and switch statements.
2026-02-11 00:07:26 +01:00
}
LibJS/Bytecode: Don't bother propagating completion values in functions The last completion value in a function is not exposed to the language, since functions always either return something, or undefined. Given this, we can avoid emitting code that propagates the completion value from various statements, as long as we know we're generating code for a context where the completion value is not accessible. In practical terms, this means that function code gets to do less completion shuffling, while global and eval code has to keep doing it.
2024-05-14 10:57:06 +02:00
if (generator.must_propagate_completion()) {
LibJS: Give try/catch/finally blocks own completion registers Each of the three blocks in a TryStatement (try body, catch body, finally body) needs its own CompletionRegisterScope so that break/continue inside any of them carries the block's own completion value rather than leaking a value from a surrounding statement or a different block. Previously, statements inside these blocks would update the enclosing scope's completion register (e.g. a for-loop's register), and if break/continue fired with no prior expression value, the enclosing register's stale value would leak through as the completion value instead of undefined. Each block now allocates a fresh register initialized to undefined and uses it as the current completion register during body generation. This matches the pattern already used by loops and switch statements.
2026-02-11 00:07:26 +01:00
if (catch_completion.has_value() && !generator.is_current_block_terminated()) {
LibJS/Bytecode: Don't bother propagating completion values in functions The last completion value in a function is not exposed to the language, since functions always either return something, or undefined. Given this, we can avoid emitting code that propagates the completion value from various statements, as long as we know we're generating code for a context where the completion value is not accessible. In practical terms, this means that function code gets to do less completion shuffling, while global and eval code has to keep doing it.
2024-05-14 10:57:06 +02:00
completion = generator.allocate_register();
LibJS: Give try/catch/finally blocks own completion registers Each of the three blocks in a TryStatement (try body, catch body, finally body) needs its own CompletionRegisterScope so that break/continue inside any of them carries the block's own completion value rather than leaking a value from a surrounding statement or a different block. Previously, statements inside these blocks would update the enclosing scope's completion register (e.g. a for-loop's register), and if break/continue fired with no prior expression value, the enclosing register's stale value would leak through as the completion value instead of undefined. Each block now allocates a fresh register initialized to undefined and uses it as the current completion register during body generation. This matches the pattern already used by loops and switch statements.
2026-02-11 00:07:26 +01:00
generator.emit_mov(*completion, *catch_completion);
LibJS/Bytecode: Don't bother propagating completion values in functions The last completion value in a function is not exposed to the language, since functions always either return something, or undefined. Given this, we can avoid emitting code that propagates the completion value from various statements, as long as we know we're generating code for a context where the completion value is not accessible. In practical terms, this means that function code gets to do less completion shuffling, while global and eval code has to keep doing it.
2024-05-14 10:57:06 +02:00
}
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
}
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
handler_target = Bytecode::Label { handler_block };
LibJS: Avoid creating empty environment for `catch` without parameter When there is no `catch` parameter to bind the error, we don't need to allocate an environment, since there's nothing to add to it. This avoids one environment allocation every time we catch like this: try { ... } catch { ... }
2023-09-25 14:11:27 +02:00
if (did_create_variable_scope_for_catch_clause)
generator.end_variable_scope();
LibJS/Bytecode: Setup declarative environment for catch with variable
2022-03-14 02:38:13 +00:00
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
if (!generator.is_current_block_terminated()) {
if (m_finalizer) {
LibJS: Use explicit completion records for try/finally dispatch Each finally scope gets two registers (completion_type and completion_value) that form an explicit completion record. Every path into the finally body sets these before jumping, and a dispatch chain after the finally body routes to the correct continuation. This replaces the old implicit protocol that relied on the exception register, a saved_return_value register, and a scheduled_jump field on ExecutionContext, allowing us to remove: - 5 opcodes (ContinuePendingUnwind, ScheduleJump, LeaveFinally, RestoreScheduledJump, PrepareYield) - 1 reserved register (saved_return_value) - 2 ExecutionContext fields (scheduled_jump, previously_scheduled_jumps)
2026-02-09 01:41:19 +01:00
// Normal exit from catch → set completion_type=Normal, jump to finally.
generator.emit_mov(finally_context->completion_type, generator.add_constant(Value(Bytecode::Generator::FinallyContext::NORMAL)));
generator.emit<Bytecode::Op::Jump>(finally_context->finally_body);
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
} else {
VERIFY(!next_block);
LibJS: Create static unwind mappings for `BasicBlock`s This is currently only used in the bytecode dump to annotate to where unwinds lead per block, but will be hooked up to the virtual machine in the next commit.
2023-10-19 23:18:54 +02:00
VERIFY(!unwind_context.has_value());
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
next_block = &generator.make_block();
LibJS: Use explicit completion records for try/finally dispatch Each finally scope gets two registers (completion_type and completion_value) that form an explicit completion record. Every path into the finally body sets these before jumping, and a dispatch chain after the finally body routes to the correct continuation. This replaces the old implicit protocol that relied on the exception register, a saved_return_value register, and a scheduled_jump field on ExecutionContext, allowing us to remove: - 5 opcodes (ContinuePendingUnwind, ScheduleJump, LeaveFinally, RestoreScheduledJump, PrepareYield) - 1 reserved register (saved_return_value) - 2 ExecutionContext fields (scheduled_jump, previously_scheduled_jumps)
2026-02-09 01:41:19 +01:00
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { *next_block });
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
}
}
}
LibJS: Use explicit completion records for try/finally dispatch Each finally scope gets two registers (completion_type and completion_value) that form an explicit completion record. Every path into the finally body sets these before jumping, and a dispatch chain after the finally body routes to the correct continuation. This replaces the old implicit protocol that relied on the exception register, a saved_return_value register, and a scheduled_jump field on ExecutionContext, allowing us to remove: - 5 opcodes (ContinuePendingUnwind, ScheduleJump, LeaveFinally, RestoreScheduledJump, PrepareYield) - 1 reserved register (saved_return_value) - 2 ExecutionContext fields (scheduled_jump, previously_scheduled_jumps)
2026-02-09 01:41:19 +01:00
LibJS: Intercept returns through finally blocks in Bytecode This is still not perfect, as we now actually crash in the `try-finally-continue` tests, while we now succeed all `try-catch-finally-*` tests. Note that we do not yet go through the finally block when exiting the unwind context through a break or continue.
2022-11-13 20:56:53 +01:00
if (m_finalizer)
generator.end_boundary(Bytecode::Generator::BlockBoundaryType::ReturnToFinally);
LibJS: Create static unwind mappings for `BasicBlock`s This is currently only used in the bytecode dump to annotate to where unwinds lead per block, but will be hooked up to the virtual machine in the next commit.
2023-10-19 23:18:54 +02:00
if (m_handler) {
LibJS: Propagate finalizers into nested try-catch blocks without them
2024-04-11 00:25:54 +02:00
if (!m_finalizer) {
auto const* parent_unwind_context = generator.current_unwind_context();
if (parent_unwind_context)
LibJS: Collapse handler/finalizer into single exception handler target After replacing the runtime unwind context stack with explicit completion records for try/finally dispatch, the distinction between "handler" (catch) and "finalizer" (finally) in the exception handler table is no longer meaningful at runtime. handle_exception() checked handler first, then finalizer, but they did the exact same thing (set the PC). When both were present, the finalizer was dead code. Collapse both fields into a single handler_offset (now non-optional, since an entry always has a target), remove the finalizer concept from BasicBlock, UnwindContext, and ExceptionHandlers, and simplify handle_exception() to a direct assignment.
2026-02-09 12:08:49 +01:00
unwind_context.emplace(generator, parent_unwind_context->handler());
LibJS: Propagate finalizers into nested try-catch blocks without them
2024-04-11 00:25:54 +02:00
else
unwind_context.emplace(generator, OptionalNone());
}
LibJS: Create static unwind mappings for `BasicBlock`s This is currently only used in the bytecode dump to annotate to where unwinds lead per block, but will be hooked up to the virtual machine in the next commit.
2023-10-19 23:18:54 +02:00
unwind_context->set_handler(handler_target.value());
}
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
LibJS: Make EnterUnwindContext a terminator op Otherwise a basic block could have multiple outgoing edges without having much reason to do so.
2021-06-13 20:39:40 +04:30
auto& target_block = generator.make_block();
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
generator.switch_to_basic_block(saved_block);
LibJS: Remove EnterUnwindContext opcode EnterUnwindContext pushed an UnwindInfo and jumped to entry_point. Without the stack push, it's just a Jump. Replace the single emission site with a Jump and remove the opcode entirely.
2026-02-09 11:19:53 +01:00
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { target_block });
LibJS: Intercept returns through finally blocks in Bytecode This is still not perfect, as we now actually crash in the `try-finally-continue` tests, while we now succeed all `try-catch-finally-*` tests. Note that we do not yet go through the finally block when exiting the unwind context through a break or continue.
2022-11-13 20:56:53 +01:00
if (m_finalizer)
generator.start_boundary(Bytecode::Generator::BlockBoundaryType::ReturnToFinally);
LibJS: Make EnterUnwindContext a terminator op Otherwise a basic block could have multiple outgoing edges without having much reason to do so.
2021-06-13 20:39:40 +04:30
generator.switch_to_basic_block(target_block);
LibJS: Give try/catch/finally blocks own completion registers Each of the three blocks in a TryStatement (try body, catch body, finally body) needs its own CompletionRegisterScope so that break/continue inside any of them carries the block's own completion value rather than leaking a value from a surrounding statement or a different block. Previously, statements inside these blocks would update the enclosing scope's completion register (e.g. a for-loop's register), and if break/continue fired with no prior expression value, the enclosing register's stale value would leak through as the completion value instead of undefined. Each block now allocates a fresh register initialized to undefined and uses it as the current completion register during body generation. This matches the pattern already used by loops and switch statements.
2026-02-11 00:07:26 +01:00
Optional<ScopedOperand> try_completion;
{
// NB: The try body needs its own completion register so that
// break/continue inside the try block carries the try's own
// completion value rather than leaking a value from an enclosing
// statement.
Optional<Bytecode::Generator::CompletionRegisterScope> completion_scope;
if (generator.must_propagate_completion()) {
try_completion = generator.allocate_register();
generator.emit_mov(*try_completion, generator.add_constant(js_undefined()));
completion_scope.emplace(generator, *try_completion);
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
(void)m_block->generate_bytecode(generator);
LibJS: Give try/catch/finally blocks own completion registers Each of the three blocks in a TryStatement (try body, catch body, finally body) needs its own CompletionRegisterScope so that break/continue inside any of them carries the block's own completion value rather than leaking a value from a surrounding statement or a different block. Previously, statements inside these blocks would update the enclosing scope's completion register (e.g. a for-loop's register), and if break/continue fired with no prior expression value, the enclosing register's stale value would leak through as the completion value instead of undefined. Each block now allocates a fresh register initialized to undefined and uses it as the current completion register during body generation. This matches the pattern already used by loops and switch statements.
2026-02-11 00:07:26 +01:00
}
LibJS: Fix codegen for nodes after try statements without 'finally' Previously we were just dropping them on the ground :P
2021-11-10 22:22:26 +03:30
if (!generator.is_current_block_terminated()) {
LibJS/Bytecode: Don't bother propagating completion values in functions The last completion value in a function is not exposed to the language, since functions always either return something, or undefined. Given this, we can avoid emitting code that propagates the completion value from various statements, as long as we know we're generating code for a context where the completion value is not accessible. In practical terms, this means that function code gets to do less completion shuffling, while global and eval code has to keep doing it.
2024-05-14 10:57:06 +02:00
if (generator.must_propagate_completion()) {
LibJS: Give try/catch/finally blocks own completion registers Each of the three blocks in a TryStatement (try body, catch body, finally body) needs its own CompletionRegisterScope so that break/continue inside any of them carries the block's own completion value rather than leaking a value from a surrounding statement or a different block. Previously, statements inside these blocks would update the enclosing scope's completion register (e.g. a for-loop's register), and if break/continue fired with no prior expression value, the enclosing register's stale value would leak through as the completion value instead of undefined. Each block now allocates a fresh register initialized to undefined and uses it as the current completion register during body generation. This matches the pattern already used by loops and switch statements.
2026-02-11 00:07:26 +01:00
if (try_completion.has_value()) {
LibJS/Bytecode: Don't bother propagating completion values in functions The last completion value in a function is not exposed to the language, since functions always either return something, or undefined. Given this, we can avoid emitting code that propagates the completion value from various statements, as long as we know we're generating code for a context where the completion value is not accessible. In practical terms, this means that function code gets to do less completion shuffling, while global and eval code has to keep doing it.
2024-05-14 10:57:06 +02:00
completion = generator.allocate_register();
LibJS: Give try/catch/finally blocks own completion registers Each of the three blocks in a TryStatement (try body, catch body, finally body) needs its own CompletionRegisterScope so that break/continue inside any of them carries the block's own completion value rather than leaking a value from a surrounding statement or a different block. Previously, statements inside these blocks would update the enclosing scope's completion register (e.g. a for-loop's register), and if break/continue fired with no prior expression value, the enclosing register's stale value would leak through as the completion value instead of undefined. Each block now allocates a fresh register initialized to undefined and uses it as the current completion register during body generation. This matches the pattern already used by loops and switch statements.
2026-02-11 00:07:26 +01:00
generator.emit_mov(*completion, *try_completion);
LibJS/Bytecode: Don't bother propagating completion values in functions The last completion value in a function is not exposed to the language, since functions always either return something, or undefined. Given this, we can avoid emitting code that propagates the completion value from various statements, as long as we know we're generating code for a context where the completion value is not accessible. In practical terms, this means that function code gets to do less completion shuffling, while global and eval code has to keep doing it.
2024-05-14 10:57:06 +02:00
}
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
}
LibJS: Fix codegen for nodes after try statements without 'finally' Previously we were just dropping them on the ground :P
2021-11-10 22:22:26 +03:30
if (m_finalizer) {
LibJS: Remove LeaveUnwindContext opcode LeaveUnwindContext popped the runtime unwind context stack. With the stack being removed, all emission sites become dead code. Remove the opcode and all its emissions.
2026-02-09 11:21:58 +01:00
// Normal exit from try → set completion_type=Normal, jump to finally.
LibJS: Use explicit completion records for try/finally dispatch Each finally scope gets two registers (completion_type and completion_value) that form an explicit completion record. Every path into the finally body sets these before jumping, and a dispatch chain after the finally body routes to the correct continuation. This replaces the old implicit protocol that relied on the exception register, a saved_return_value register, and a scheduled_jump field on ExecutionContext, allowing us to remove: - 5 opcodes (ContinuePendingUnwind, ScheduleJump, LeaveFinally, RestoreScheduledJump, PrepareYield) - 1 reserved register (saved_return_value) - 2 ExecutionContext fields (scheduled_jump, previously_scheduled_jumps)
2026-02-09 01:41:19 +01:00
generator.emit_mov(finally_context->completion_type, generator.add_constant(Value(Bytecode::Generator::FinallyContext::NORMAL)));
generator.emit<Bytecode::Op::Jump>(finally_context->finally_body);
LibJS: Fix codegen for nodes after try statements without 'finally' Previously we were just dropping them on the ground :P
2021-11-10 22:22:26 +03:30
} else {
LibJS: Create static unwind mappings for `BasicBlock`s This is currently only used in the bytecode dump to annotate to where unwinds lead per block, but will be hooked up to the virtual machine in the next commit.
2023-10-19 23:18:54 +02:00
VERIFY(unwind_context.has_value());
unwind_context.clear();
LibJS/Bytecode: Fix bogus program termination after `try` with `catch` For `try` statements with a `catch` clause, we were generating *two* "next" blocks. This meant that not throwing an exception would cause execution to stop. Fix this by using the "next" block pointer for the try "entry" and "handler" blocks.
2023-05-13 18:50:27 +02:00
if (!next_block)
next_block = &generator.make_block();
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { *next_block });
LibJS: Fix codegen for nodes after try statements without 'finally' Previously we were just dropping them on the ground :P
2021-11-10 22:22:26 +03:30
}
}
LibJS: Intercept returns through finally blocks in Bytecode This is still not perfect, as we now actually crash in the `try-finally-continue` tests, while we now succeed all `try-catch-finally-*` tests. Note that we do not yet go through the finally block when exiting the unwind context through a break or continue.
2022-11-13 20:56:53 +01:00
if (m_finalizer)
generator.end_boundary(Bytecode::Generator::BlockBoundaryType::ReturnToFinally);
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
LibJS: Use explicit completion records for try/finally dispatch Each finally scope gets two registers (completion_type and completion_value) that form an explicit completion record. Every path into the finally body sets these before jumping, and a dispatch chain after the finally body routes to the correct continuation. This replaces the old implicit protocol that relied on the exception register, a saved_return_value register, and a scheduled_jump field on ExecutionContext, allowing us to remove: - 5 opcodes (ContinuePendingUnwind, ScheduleJump, LeaveFinally, RestoreScheduledJump, PrepareYield) - 1 reserved register (saved_return_value) - 2 ExecutionContext fields (scheduled_jump, previously_scheduled_jumps)
2026-02-09 01:41:19 +01:00
// Now generate the finally body and after-finally dispatch.
// We deferred this so that registered_jumps from break/continue in the try body are available.
if (m_finalizer && finally_context.has_value()) {
generator.set_current_finally_context(finally_context->parent);
// Clear the unwind context so that blocks created during finally body generation
// don't inherit the inner handler/finalizer (the inner unwind context is already
// popped at runtime by the time the finally body runs).
unwind_context.clear();
generator.switch_to_basic_block(*finally_body_block_ptr);
generator.start_boundary(Bytecode::Generator::BlockBoundaryType::LeaveFinally);
LibJS: Give try/catch/finally blocks own completion registers Each of the three blocks in a TryStatement (try body, catch body, finally body) needs its own CompletionRegisterScope so that break/continue inside any of them carries the block's own completion value rather than leaking a value from a surrounding statement or a different block. Previously, statements inside these blocks would update the enclosing scope's completion register (e.g. a for-loop's register), and if break/continue fired with no prior expression value, the enclosing register's stale value would leak through as the completion value instead of undefined. Each block now allocates a fresh register initialized to undefined and uses it as the current completion register during body generation. This matches the pattern already used by loops and switch statements.
2026-02-11 00:07:26 +01:00
{
// NB: The finally body needs its own completion register so that
// break/continue inside the finally block carries the finally's
// own completion value (initialized to undefined) rather than
// leaking the try/catch block's completion value through.
Optional<ScopedOperand> finally_completion;
Optional<Bytecode::Generator::CompletionRegisterScope> completion_scope;
if (generator.must_propagate_completion()) {
finally_completion = generator.allocate_register();
generator.emit_mov(*finally_completion, generator.add_constant(js_undefined()));
completion_scope.emplace(generator, *finally_completion);
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
(void)m_finalizer->generate_bytecode(generator);
LibJS: Give try/catch/finally blocks own completion registers Each of the three blocks in a TryStatement (try body, catch body, finally body) needs its own CompletionRegisterScope so that break/continue inside any of them carries the block's own completion value rather than leaking a value from a surrounding statement or a different block. Previously, statements inside these blocks would update the enclosing scope's completion register (e.g. a for-loop's register), and if break/continue fired with no prior expression value, the enclosing register's stale value would leak through as the completion value instead of undefined. Each block now allocates a fresh register initialized to undefined and uses it as the current completion register during body generation. This matches the pattern already used by loops and switch statements.
2026-02-11 00:07:26 +01:00
}
LibJS: Use explicit completion records for try/finally dispatch Each finally scope gets two registers (completion_type and completion_value) that form an explicit completion record. Every path into the finally body sets these before jumping, and a dispatch chain after the finally body routes to the correct continuation. This replaces the old implicit protocol that relied on the exception register, a saved_return_value register, and a scheduled_jump field on ExecutionContext, allowing us to remove: - 5 opcodes (ContinuePendingUnwind, ScheduleJump, LeaveFinally, RestoreScheduledJump, PrepareYield) - 1 reserved register (saved_return_value) - 2 ExecutionContext fields (scheduled_jump, previously_scheduled_jumps)
2026-02-09 01:41:19 +01:00
generator.end_boundary(Bytecode::Generator::BlockBoundaryType::LeaveFinally);
if (!generator.is_current_block_terminated()) {
if (!next_block)
next_block = &generator.make_block();
auto const& completion_type = finally_context->completion_type;
auto const& completion_value = finally_context->completion_value;
// After-finally dispatch chain: a series of JumpStrictlyEquals that check
// completion_type and route to the right continuation. Order:
// 1. NORMAL → fall through to next block
// 2. Each registered break/continue target
// 3. RETURN → return/yield the completion_value
// 4. Default → rethrow completion_value (must be THROW)
auto& after_normal_check = generator.make_block();
generator.emit<Bytecode::Op::JumpStrictlyEquals>(
completion_type, generator.add_constant(Value(Bytecode::Generator::FinallyContext::NORMAL)),
Bytecode::Label { *next_block }, Bytecode::Label { after_normal_check });
generator.switch_to_basic_block(after_normal_check);
// Registered break/continue jumps (indices 3+)
for (auto const& jump : finally_context->registered_jumps) {
auto& after_jump_check = generator.make_block();
generator.emit<Bytecode::Op::JumpStrictlyEquals>(
completion_type, generator.add_constant(Value(jump.index)),
jump.target, Bytecode::Label { after_jump_check });
generator.switch_to_basic_block(after_jump_check);
}
auto& return_block = generator.make_block();
auto& rethrow_block = generator.make_block();
generator.emit<Bytecode::Op::JumpStrictlyEquals>(
completion_type, generator.add_constant(Value(Bytecode::Generator::FinallyContext::RETURN)),
Bytecode::Label { return_block }, Bytecode::Label { rethrow_block });
// Generate return block.
generator.switch_to_basic_block(return_block);
if (finally_context->parent) {
// Nested finally: copy completion record to outer and jump to outer finally body.
auto& outer = *finally_context->parent;
generator.emit_mov(outer.completion_type, completion_type);
generator.emit_mov(outer.completion_value, completion_value);
generator.emit<Bytecode::Op::Jump>(outer.finally_body);
} else {
if (generator.is_in_generator_function()) {
generator.emit<Bytecode::Op::Yield>(OptionalNone {}, completion_value);
} else {
generator.emit<Bytecode::Op::Return>(completion_value);
}
}
// Default: rethrow the exception.
generator.switch_to_basic_block(rethrow_block);
generator.emit<Bytecode::Op::Throw>(completion_value);
}
}
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
generator.switch_to_basic_block(next_block ? *next_block : saved_block);
LibJS/Bytecode: Don't bother propagating completion values in functions The last completion value in a function is not exposed to the language, since functions always either return something, or undefined. Given this, we can avoid emitting code that propagates the completion value from various statements, as long as we know we're generating code for a context where the completion value is not accessible. In practical terms, this means that function code gets to do less completion shuffling, while global and eval code has to keep doing it.
2024-05-14 10:57:06 +02:00
if (generator.must_propagate_completion()) {
if (!completion.has_value())
return generator.add_constant(js_undefined());
}
return completion;
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> SwitchStatement::generate_bytecode(Bytecode::Generator& generator, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
return generate_labelled_evaluation(generator, {});
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> SwitchStatement::generate_labelled_evaluation(Bytecode::Generator& generator, Vector<FlyString> const& label_set, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS: Implement bytecode generation for switch
2021-06-11 00:36:16 +02:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
LibJS/Bytecode: Don't bother propagating completion values in functions The last completion value in a function is not exposed to the language, since functions always either return something, or undefined. Given this, we can avoid emitting code that propagates the completion value from various statements, as long as we know we're generating code for a context where the completion value is not accessible. In practical terms, this means that function code gets to do less completion shuffling, while global and eval code has to keep doing it.
2024-05-14 10:57:06 +02:00
Optional<ScopedOperand> completion;
if (generator.must_propagate_completion()) {
completion = generator.allocate_register();
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(*completion, generator.add_constant(js_undefined()));
LibJS/Bytecode: Don't bother propagating completion values in functions The last completion value in a function is not exposed to the language, since functions always either return something, or undefined. Given this, we can avoid emitting code that propagates the completion value from various statements, as long as we know we're generating code for a context where the completion value is not accessible. In practical terms, this means that function code gets to do less completion shuffling, while global and eval code has to keep doing it.
2024-05-14 10:57:06 +02:00
}
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto discriminant = m_discriminant->generate_bytecode(generator).value();
LibJS: Implement bytecode generation for switch
2021-06-11 00:36:16 +02:00
Vector<Bytecode::BasicBlock&> case_blocks;
LibJS/Bytecode: Keep completion value of switch case if falling through We do this by moving the `LoadImmediate undefined` instruction to a separate basic block which jumps to the case's block unconditionally. We enter a case initially using this wrapper, but when falling through, we directly jump to the next case's block.
2023-06-28 11:45:19 +02:00
Bytecode::BasicBlock* entry_block_for_default { nullptr };
LibJS: Implement bytecode generation for switch
2021-06-11 00:36:16 +02:00
Bytecode::BasicBlock* next_test_block = &generator.make_block();
LibJS: Actually generate a lexical env for SwitchStatement in BC We had code for this in ScopeNode, but that function was never called for a SwitchStatement. This fixes a bunch of scoping tests for switch.
2022-04-03 02:13:51 +04:30
LibJS/Bytecode: Don't create empty lexical environments This patch stops emitting the BlockDeclarationInstantiation instruction when there are no locals, and no function declarations in the scope. We were spending 20% of CPU time on https://ventrella.com/Clusters/ just creating empty environments for no reason.
2024-05-11 13:25:08 +02:00
bool did_create_lexical_environment = false;
if (has_lexical_declarations())
did_create_lexical_environment = generator.emit_block_declaration_instantiation(*this);
LibJS: Actually generate a lexical env for SwitchStatement in BC We had code for this in ScopeNode, but that function was never called for a SwitchStatement. This fixes a bunch of scoping tests for switch.
2022-04-03 02:13:51 +04:30
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { *next_test_block });
LibJS: Actually generate a lexical env for SwitchStatement in BC We had code for this in ScopeNode, but that function was never called for a SwitchStatement. This fixes a bunch of scoping tests for switch.
2022-04-03 02:13:51 +04:30
LibJS/Bytecode: Bunch all tests together in switch statement codegen Before this change, switch codegen would interleave bytecode like this: (test for case 1) (code for case 1) (test for case 2) (code for case 2) This meant that we often had to make many large jumps while looking for the matching case, since code for each case can be huge. It now looks like this instead: (test for case 1) (test for case 2) (code for case 1) (code for case 2) This way, we can just fall through the tests until we hit one that fits, without having to make any large jumps.
2024-05-08 13:08:38 +02:00
Queue<Bytecode::BasicBlock*> test_blocks;
for (auto& switch_case : m_cases) {
if (switch_case->test())
test_blocks.enqueue(&generator.make_block());
}
LibJS: Implement bytecode generation for switch
2021-06-11 00:36:16 +02:00
for (auto& switch_case : m_cases) {
auto& case_block = generator.make_block();
Everywhere: Stop using NonnullRefPtrVector This class had slightly confusing semantics and the added weirdness doesn't seem worth it just so we can say "." instead of "->" when iterating over a vector of NNRPs. This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
2023-03-06 14:17:01 +01:00
if (switch_case->test()) {
LibJS: Implement bytecode generation for switch
2021-06-11 00:36:16 +02:00
generator.switch_to_basic_block(*next_test_block);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto test_value = switch_case->test()->generate_bytecode(generator).value();
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto result = generator.allocate_register();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::StrictlyEquals>(result, test_value, discriminant);
LibJS/Bytecode: Bunch all tests together in switch statement codegen Before this change, switch codegen would interleave bytecode like this: (test for case 1) (code for case 1) (test for case 2) (code for case 2) This meant that we often had to make many large jumps while looking for the matching case, since code for each case can be huge. It now looks like this instead: (test for case 1) (test for case 2) (code for case 1) (code for case 2) This way, we can just fall through the tests until we hit one that fits, without having to make any large jumps.
2024-05-08 13:08:38 +02:00
next_test_block = test_blocks.dequeue();
LibJS/Bytecode: Do basic compare-and-jump peephole optimization We now fuse sequences like [LessThan, JumpIf] to JumpLessThan. This is only allowed for temporaries (i.e VM registers) with no other references to them.
2024-05-09 15:13:31 +02:00
generator.emit_jump_if(
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
result,
LibJS/Bytecode: Remove pointless basic block in SwitchStatement codegen
2024-05-08 12:55:32 +02:00
Bytecode::Label { case_block },
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
Bytecode::Label { *next_test_block });
LibJS: Implement bytecode generation for switch
2021-06-11 00:36:16 +02:00
} else {
LibJS/Bytecode: Remove pointless basic block in SwitchStatement codegen
2024-05-08 12:55:32 +02:00
entry_block_for_default = &case_block;
LibJS: Implement bytecode generation for switch
2021-06-11 00:36:16 +02:00
}
LibJS/Bytecode: Keep completion value of switch case if falling through We do this by moving the `LoadImmediate undefined` instruction to a separate basic block which jumps to the case's block unconditionally. We enter a case initially using this wrapper, but when falling through, we directly jump to the next case's block.
2023-06-28 11:45:19 +02:00
LibJS: Implement bytecode generation for switch
2021-06-11 00:36:16 +02:00
case_blocks.append(case_block);
}
generator.switch_to_basic_block(*next_test_block);
auto& end_block = generator.make_block();
LibJS/Bytecode: Keep completion value of switch case if falling through We do this by moving the `LoadImmediate undefined` instruction to a separate basic block which jumps to the case's block unconditionally. We enter a case initially using this wrapper, but when falling through, we directly jump to the next case's block.
2023-06-28 11:45:19 +02:00
if (entry_block_for_default != nullptr) {
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { *entry_block_for_default });
LibJS: Implement bytecode generation for switch
2021-06-11 00:36:16 +02:00
} else {
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { end_block });
LibJS: Implement bytecode generation for switch
2021-06-11 00:36:16 +02:00
}
auto current_block = case_blocks.begin();
LibJS: Fix UpdateEmpty completion value semantics for loops/switch/if When a loop or switch body produces an abrupt completion (break or continue) with an empty value, the ES spec requires UpdateEmpty to replace the empty value with the last non-empty completion value V. The bytecode compiler was failing to do this because it only updated the completion register after body codegen, guarded by !is_current_block_terminated(). When break/continue terminated the block, the update was skipped. Fix this with three changes: 1. Introduce a CompletionRegisterScope that tells ScopeNode::generate_bytecode to eagerly emit Mov instructions into the completion register after each value-producing statement. This ensures the register is up to date before any break or continue fires. 2. Give IfStatement its own CompletionRegisterScope (initialized to undefined) during branch evaluation. This models the spec's UpdateEmpty(stmtCompletion, undefined) for if-statements: when break/continue fires inside an if-branch, the scoped jump propagation sees that the if's completion register differs from the loop's and emits a Mov, correctly replacing the eagerly written value with undefined. Without this, code like { 3; if (true) { break; } else { } } would incorrectly carry the value 3 instead of undefined through the break. 3. Capture loop body results and emit a fallback Mov for non-ScopeNode bodies (e.g. bare expression statements like do x=1; while(false)) that don't participate in the eager CompletionRegisterScope update mechanism. For labelled break/continue that cross loop boundaries, the jump codegen now propagates the inner completion register to the target scope's completion register before emitting the jump. Also fix ForStatement to use a proper completion register (previously it returned the body result directly, which was wrong for empty bodies and break-with-no-value cases).
2026-02-10 23:25:24 +01:00
generator.begin_breakable_scope(Bytecode::Label { end_block }, label_set, completion);
LibJS: Implement bytecode generation for switch
2021-06-11 00:36:16 +02:00
for (auto& switch_case : m_cases) {
generator.switch_to_basic_block(*current_block);
LibJS: Fix UpdateEmpty completion value semantics for loops/switch/if When a loop or switch body produces an abrupt completion (break or continue) with an empty value, the ES spec requires UpdateEmpty to replace the empty value with the last non-empty completion value V. The bytecode compiler was failing to do this because it only updated the completion register after body codegen, guarded by !is_current_block_terminated(). When break/continue terminated the block, the update was skipped. Fix this with three changes: 1. Introduce a CompletionRegisterScope that tells ScopeNode::generate_bytecode to eagerly emit Mov instructions into the completion register after each value-producing statement. This ensures the register is up to date before any break or continue fires. 2. Give IfStatement its own CompletionRegisterScope (initialized to undefined) during branch evaluation. This models the spec's UpdateEmpty(stmtCompletion, undefined) for if-statements: when break/continue fires inside an if-branch, the scoped jump propagation sees that the if's completion register differs from the loop's and emits a Mov, correctly replacing the eagerly written value with undefined. Without this, code like { 3; if (true) { break; } else { } } would incorrectly carry the value 3 instead of undefined through the break. 3. Capture loop body results and emit a fallback Mov for non-ScopeNode bodies (e.g. bare expression statements like do x=1; while(false)) that don't participate in the eager CompletionRegisterScope update mechanism. For labelled break/continue that cross loop boundaries, the jump codegen now propagates the inner completion register to the target scope's completion register before emitting the jump. Also fix ForStatement to use a proper completion register (previously it returned the body result directly, which was wrong for empty bodies and break-with-no-value cases).
2026-02-10 23:25:24 +01:00
{
Optional<Bytecode::Generator::CompletionRegisterScope> completion_scope;
if (completion.has_value())
completion_scope.emplace(generator, *completion);
for (auto& statement : switch_case->children()) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto result = statement->generate_bytecode(generator);
LibJS: Fix UpdateEmpty completion value semantics for loops/switch/if When a loop or switch body produces an abrupt completion (break or continue) with an empty value, the ES spec requires UpdateEmpty to replace the empty value with the last non-empty completion value V. The bytecode compiler was failing to do this because it only updated the completion register after body codegen, guarded by !is_current_block_terminated(). When break/continue terminated the block, the update was skipped. Fix this with three changes: 1. Introduce a CompletionRegisterScope that tells ScopeNode::generate_bytecode to eagerly emit Mov instructions into the completion register after each value-producing statement. This ensures the register is up to date before any break or continue fires. 2. Give IfStatement its own CompletionRegisterScope (initialized to undefined) during branch evaluation. This models the spec's UpdateEmpty(stmtCompletion, undefined) for if-statements: when break/continue fires inside an if-branch, the scoped jump propagation sees that the if's completion register differs from the loop's and emits a Mov, correctly replacing the eagerly written value with undefined. Without this, code like { 3; if (true) { break; } else { } } would incorrectly carry the value 3 instead of undefined through the break. 3. Capture loop body results and emit a fallback Mov for non-ScopeNode bodies (e.g. bare expression statements like do x=1; while(false)) that don't participate in the eager CompletionRegisterScope update mechanism. For labelled break/continue that cross loop boundaries, the jump codegen now propagates the inner completion register to the target scope's completion register before emitting the jump. Also fix ForStatement to use a proper completion register (previously it returned the body result directly, which was wrong for empty bodies and break-with-no-value cases).
2026-02-10 23:25:24 +01:00
if (generator.is_current_block_terminated())
break;
if (generator.must_propagate_completion()) {
if (result.has_value())
generator.emit_mov(*completion, *result);
}
LibJS/Bytecode: Don't bother propagating completion values in functions The last completion value in a function is not exposed to the language, since functions always either return something, or undefined. Given this, we can avoid emitting code that propagates the completion value from various statements, as long as we know we're generating code for a context where the completion value is not accessible. In practical terms, this means that function code gets to do less completion shuffling, while global and eval code has to keep doing it.
2024-05-14 10:57:06 +02:00
}
LibJS: Implement bytecode generation for switch
2021-06-11 00:36:16 +02:00
}
if (!generator.is_current_block_terminated()) {
auto next_block = current_block;
next_block++;
if (next_block.is_end()) {
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { end_block });
LibJS: Implement bytecode generation for switch
2021-06-11 00:36:16 +02:00
} else {
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { *next_block });
LibJS: Implement bytecode generation for switch
2021-06-11 00:36:16 +02:00
}
}
current_block++;
}
generator.end_breakable_scope();
generator.switch_to_basic_block(end_block);
LibJS/Bytecode: Actually exit `switch` statement's lexical scope 95 new passes on test262. :^)
2023-06-25 07:37:24 +02:00
LibJS/Bytecode: Don't create empty lexical environments This patch stops emitting the BlockDeclarationInstantiation instruction when there are no locals, and no function declarations in the scope. We were spending 20% of CPU time on https://ventrella.com/Clusters/ just creating empty environments for no reason.
2024-05-11 13:25:08 +02:00
if (did_create_lexical_environment)
LibJS/Bytecode: Actually exit `switch` statement's lexical scope 95 new passes on test262. :^)
2023-06-25 07:37:24 +02:00
generator.end_variable_scope();
LibJS/Bytecode: Don't bother propagating completion values in functions The last completion value in a function is not exposed to the language, since functions always either return something, or undefined. Given this, we can avoid emitting code that propagates the completion value from various statements, as long as we know we're generating code for a context where the completion value is not accessible. In practical terms, this means that function code gets to do less completion shuffling, while global and eval code has to keep doing it.
2024-05-14 10:57:06 +02:00
return completion;
LibJS: Implement bytecode generation for switch
2021-06-11 00:36:16 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> SuperExpression::generate_bytecode(Bytecode::Generator&, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS/Bytecode: Ensure we do not generate bytecode for super expressions Similar to AST mode, super expressions are handled elsewhere.
2023-07-06 17:16:20 -04:00
{
// The semantics for SuperExpression are handled in CallExpression and SuperCall.
VERIFY_NOT_REACHED();
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> ClassDeclaration::generate_bytecode(Bytecode::Generator& generator, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS: NewClass bytecode instruction This adds a the NewClass bytecode instruction, enough of it is implemented for it to show it in the bytecode (js -d).
2021-06-30 15:42:13 -03:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto value = m_class_expression->generate_bytecode(generator).value();
LibJS/Bytecode: Split SetVariable into four separate instructions Instead of SetVariable having 2x2 modes for variable/lexical and initialize/set, those 4 modes are now separate instructions, which makes each instruction much less branchy.
2024-05-14 11:30:30 +02:00
generator.emit_set_variable(*m_class_expression.ptr()->m_name, value, Bytecode::Op::BindingInitializationMode::Initialize);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
// NOTE: ClassDeclaration does not produce a value.
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
return Optional<ScopedOperand> {};
LibJS: Implement ClassExpression::generate_bytecode() ...and use that in ClassDeclaration::generate_bytecode().
2022-02-12 19:55:40 +03:30
}
LibJS: Stop using execute_ast_node in NewClass instruction This change replaces usage of `execute_ast_node` to evaluate super expression in NewClass by generating instructions instead.
2023-06-28 18:22:27 +03:00
// 15.7.14 Runtime Semantics: ClassDefinitionEvaluation, https://tc39.es/ecma262/#sec-runtime-semantics-classdefinitionevaluation
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> ClassExpression::generate_bytecode_with_lhs_name(Bytecode::Generator& generator, Optional<Bytecode::IdentifierTableIndex> lhs_name, Optional<ScopedOperand> preferred_dst) const
LibJS: Implement ClassExpression::generate_bytecode() ...and use that in ClassDeclaration::generate_bytecode().
2022-02-12 19:55:40 +03:30
{
LibJS: Stop using execute_ast_node in NewClass instruction This change replaces usage of `execute_ast_node` to evaluate super expression in NewClass by generating instructions instead.
2023-06-28 18:22:27 +03:00
// NOTE: Step 2 is not a part of NewClass instruction because it is assumed to be done before super class expression evaluation
LibJS: Replace implicit environment stack with explicit registers Replace the saved_lexical_environments stack in ExecutionContextRareData with explicit register-based environment tracking. Environments are now stored in registers and restored via SetLexicalEnvironment, making the environment flow visible in bytecode. Key changes: - Add GetLexicalEnvironment and SetLexicalEnvironment opcodes - CreateLexicalEnvironment takes explicit parent and dst operands - EnterObjectEnvironment stores new environment in a dst register - NewClass takes an explicit class_environment operand - Remove LeaveLexicalEnvironment opcode (instead: SetLexicalEnvironment) - Remove saved_lexical_environments from ExecutionContextRareData - Use a reserved register for the saved lexical environment to avoid dominance issues with lazily-emitted GetLexicalEnvironment
2026-02-09 03:34:42 +01:00
auto parent_environment = generator.current_lexical_environment_register();
auto class_environment = generator.allocate_register();
generator.emit<Bytecode::Op::CreateLexicalEnvironment>(class_environment, parent_environment, 0);
generator.push_lexical_environment_register(class_environment);
LibJS: Stop using execute_ast_node in NewClass instruction This change replaces usage of `execute_ast_node` to evaluate super expression in NewClass by generating instructions instead.
2023-06-28 18:22:27 +03:00
if (has_name() || !lhs_name.has_value()) {
// NOTE: Step 3.a is not a part of NewClass instruction because it is assumed to be done before super class expression evaluation
LibJS: Use Identifier to represent name of ClassExpression By using Identifier class to represent the name of a class expression, it becomes possible to consistently store information within the identifier object, indicating whether the name refers to a local variable or not.
2023-06-30 16:51:39 +03:00
auto interned_index = generator.intern_identifier(name());
LibJS: Generate C++ bytecode instruction classes from a definition file This commit adds a new Bytecode.def file that describes all the LibJS bytecode instructions. From this, we are able to generate the full declarations for all C++ bytecode instruction classes, as well as their serialization code. Note that some of the bytecode compiler was updated since instructions no longer have default constructor arguments. The big immediate benefit here is that we lose a couple thousand lines of hand-written C++ code. Going forward, this also allows us to do more tooling for the bytecode VM, now that we have an authoritative description of its instructions. Key things to know about: - Instructions can inherit from one another. At the moment, everything simply inherits from the base "Instruction". - @terminator means the instruction terminates a basic block. - @nothrow means the instruction cannot throw. This affects how the interpreter interacts with it. - Variable-length instructions are automatically supported. Just put an array of something as the last field of the instruction. - The m_length field is magical. If present, it will be populated with the full length of the instruction. This is used for variable-length instructions.
2025-11-20 22:14:50 +01:00
generator.emit<Bytecode::Op::CreateVariable>(interned_index, Bytecode::Op::EnvironmentMode::Lexical, true, false, false);
LibJS: Stop using execute_ast_node in NewClass instruction This change replaces usage of `execute_ast_node` to evaluate super expression in NewClass by generating instructions instead.
2023-06-28 18:22:27 +03:00
}
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
Optional<ScopedOperand> super_class;
LibJS: Stop using execute_ast_node in NewClass instruction This change replaces usage of `execute_ast_node` to evaluate super expression in NewClass by generating instructions instead.
2023-06-28 18:22:27 +03:00
if (m_super_class)
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
super_class = m_super_class->generate_bytecode(generator).value();
LibJS: Stop using execute_ast_node in NewClass instruction This change replaces usage of `execute_ast_node` to evaluate super expression in NewClass by generating instructions instead.
2023-06-28 18:22:27 +03:00
LibJS: Skip PrivateEnvironment allocation if possible If class doesn't have any private fields, we could avoid allocating PrivateEnvironment for it. This allows us to skip thousands of unnecessary PrivateEnvironment allocations on Discord.
2025-07-30 12:10:17 +02:00
bool did_emit_private_environment_allocation = false;
LibJS: Stop using execute_ast_node() for class property evaluation Instead, generate bytecode to execute their AST nodes and save the resulting operands inside the NewClass instruction. Moving property expression evaluation to happen before NewClass execution also moves along creation of new private environment and its population with private members (private members should be visible during property evaluation). Before: - NewClass After: - CreatePrivateEnvironment - AddPrivateName - ... - AddPrivateName - NewClass - LeavePrivateEnvironment
2024-05-11 22:54:41 +00:00
for (auto const& element : m_elements) {
auto opt_private_name = element->private_bound_identifier();
if (opt_private_name.has_value()) {
LibJS: Skip PrivateEnvironment allocation if possible If class doesn't have any private fields, we could avoid allocating PrivateEnvironment for it. This allows us to skip thousands of unnecessary PrivateEnvironment allocations on Discord.
2025-07-30 12:10:17 +02:00
if (!did_emit_private_environment_allocation) {
generator.emit<Op::CreatePrivateEnvironment>();
did_emit_private_environment_allocation = true;
}
LibJS: Stop using execute_ast_node() for class property evaluation Instead, generate bytecode to execute their AST nodes and save the resulting operands inside the NewClass instruction. Moving property expression evaluation to happen before NewClass execution also moves along creation of new private environment and its population with private members (private members should be visible during property evaluation). Before: - NewClass After: - CreatePrivateEnvironment - AddPrivateName - ... - AddPrivateName - NewClass - LeavePrivateEnvironment
2024-05-11 22:54:41 +00:00
generator.emit<Op::AddPrivateName>(generator.intern_identifier(*opt_private_name));
}
}
Vector<Optional<ScopedOperand>> elements;
for (auto const& element : m_elements) {
Optional<ScopedOperand> key;
if (is<ClassMethod>(*element)) {
auto const& class_method = static_cast<ClassMethod const&>(*element);
if (!is<PrivateIdentifier>(class_method.key()))
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
key = class_method.key().generate_bytecode(generator);
LibJS: Stop using execute_ast_node() for class property evaluation Instead, generate bytecode to execute their AST nodes and save the resulting operands inside the NewClass instruction. Moving property expression evaluation to happen before NewClass execution also moves along creation of new private environment and its population with private members (private members should be visible during property evaluation). Before: - NewClass After: - CreatePrivateEnvironment - AddPrivateName - ... - AddPrivateName - NewClass - LeavePrivateEnvironment
2024-05-11 22:54:41 +00:00
} else if (is<ClassField>(*element)) {
auto const& class_field = static_cast<ClassField const&>(*element);
if (!is<PrivateIdentifier>(class_field.key()))
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
key = class_field.key().generate_bytecode(generator);
LibJS: Stop using execute_ast_node() for class property evaluation Instead, generate bytecode to execute their AST nodes and save the resulting operands inside the NewClass instruction. Moving property expression evaluation to happen before NewClass execution also moves along creation of new private environment and its population with private members (private members should be visible during property evaluation). Before: - NewClass After: - CreatePrivateEnvironment - AddPrivateName - ... - AddPrivateName - NewClass - LeavePrivateEnvironment
2024-05-11 22:54:41 +00:00
}
elements.append({ key });
}
LibJS: Populate ClassBlueprint during codegen Build a ClassBlueprint from ClassExpression elements at codegen time: - Methods/getters/setters: register SharedFunctionInstanceData from the method's FunctionExpression - Field initializers with literal values (numbers, booleans, null, strings, negated numbers): store the value directly, avoiding function creation entirely - Field initializers with non-literal values: wrap in ClassFieldInitializerStatement and create SharedFunctionInstanceData - Static initializers: create SharedFunctionInstanceData from the function body - Constructor: register SharedFunctionInstanceData from the constructor's FunctionExpression Add public accessors to ClassMethod::function() and StaticInitializer::function_body() for codegen access. The blueprint is registered but not yet used by NewClass (dual path). No behavioral change.
2026-02-11 00:20:47 +01:00
// Build a ClassBlueprint that captures all class element metadata at codegen time.
auto& vm = generator.vm();
ClassBlueprint blueprint;
blueprint.has_super_class = !m_super_class.is_null();
blueprint.has_name = has_name();
blueprint.name = name();
blueprint.source_text = source_text();
// Register shared function data for the constructor.
LibJS: Move SharedFunctionInstanceData creation out of FunctionNode Add static factory methods create_for_function_node() on SharedFunctionInstanceData and update all callers to use them instead of FunctionNode::ensure_shared_data(). This removes the GC::Root<SharedFunctionInstanceData> cache from FunctionNode, eliminating the coupling between the RefCounted AST and GC-managed runtime objects. The cache was effectively dead code: hoisted declarations use m_functions_to_initialize directly, and function expressions always create fresh instances during codegen.
2026-02-11 11:51:48 +01:00
auto constructor_shared_data = SharedFunctionInstanceData::create_for_function_node(vm, *m_constructor);
LibJS: Populate ClassBlueprint during codegen Build a ClassBlueprint from ClassExpression elements at codegen time: - Methods/getters/setters: register SharedFunctionInstanceData from the method's FunctionExpression - Field initializers with literal values (numbers, booleans, null, strings, negated numbers): store the value directly, avoiding function creation entirely - Field initializers with non-literal values: wrap in ClassFieldInitializerStatement and create SharedFunctionInstanceData - Static initializers: create SharedFunctionInstanceData from the function body - Constructor: register SharedFunctionInstanceData from the constructor's FunctionExpression Add public accessors to ClassMethod::function() and StaticInitializer::function_body() for codegen access. The blueprint is registered but not yet used by NewClass (dual path). No behavioral change.
2026-02-11 00:20:47 +01:00
blueprint.constructor_shared_function_data_index = generator.register_shared_function_data(constructor_shared_data);
for (auto const& element : m_elements) {
if (is<ClassMethod>(*element)) {
auto const& class_method = static_cast<ClassMethod const&>(*element);
bool is_private = is<PrivateIdentifier>(class_method.key());
ClassElementDescriptor::Kind descriptor_kind;
switch (class_method.kind()) {
case ClassMethod::Kind::Method:
descriptor_kind = ClassElementDescriptor::Kind::Method;
break;
case ClassMethod::Kind::Getter:
descriptor_kind = ClassElementDescriptor::Kind::Getter;
break;
case ClassMethod::Kind::Setter:
descriptor_kind = ClassElementDescriptor::Kind::Setter;
break;
}
LibJS: Move SharedFunctionInstanceData creation out of FunctionNode Add static factory methods create_for_function_node() on SharedFunctionInstanceData and update all callers to use them instead of FunctionNode::ensure_shared_data(). This removes the GC::Root<SharedFunctionInstanceData> cache from FunctionNode, eliminating the coupling between the RefCounted AST and GC-managed runtime objects. The cache was effectively dead code: hoisted declarations use m_functions_to_initialize directly, and function expressions always create fresh instances during codegen.
2026-02-11 11:51:48 +01:00
auto shared_data = SharedFunctionInstanceData::create_for_function_node(vm, class_method.function());
LibJS: Populate ClassBlueprint during codegen Build a ClassBlueprint from ClassExpression elements at codegen time: - Methods/getters/setters: register SharedFunctionInstanceData from the method's FunctionExpression - Field initializers with literal values (numbers, booleans, null, strings, negated numbers): store the value directly, avoiding function creation entirely - Field initializers with non-literal values: wrap in ClassFieldInitializerStatement and create SharedFunctionInstanceData - Static initializers: create SharedFunctionInstanceData from the function body - Constructor: register SharedFunctionInstanceData from the constructor's FunctionExpression Add public accessors to ClassMethod::function() and StaticInitializer::function_body() for codegen access. The blueprint is registered but not yet used by NewClass (dual path). No behavioral change.
2026-02-11 00:20:47 +01:00
auto data_index = generator.register_shared_function_data(shared_data);
blueprint.elements.append({
.kind = descriptor_kind,
.is_static = element->is_static(),
.is_private = is_private,
.private_identifier = is_private ? Optional<Utf16FlyString>(static_cast<PrivateIdentifier const&>(class_method.key()).string()) : Optional<Utf16FlyString>(),
.shared_function_data_index = data_index,
.has_initializer = false,
.literal_value = {},
});
} else if (is<ClassField>(*element)) {
auto const& class_field = static_cast<ClassField const&>(*element);
bool is_private = is<PrivateIdentifier>(class_field.key());
Optional<u32> data_index;
bool has_initializer = class_field.initializer() != nullptr;
Optional<Value> literal_value;
if (has_initializer) {
auto const& initializer = *class_field.initializer();
// Detect literal initializers and store the value directly,
// avoiding function creation and calls for simple cases like x = 0.
if (is<NumericLiteral>(initializer)) {
literal_value = static_cast<NumericLiteral const&>(initializer).value();
} else if (is<BooleanLiteral>(initializer)) {
literal_value = static_cast<BooleanLiteral const&>(initializer).value();
} else if (is<NullLiteral>(initializer)) {
literal_value = js_null();
} else if (is<StringLiteral>(initializer)) {
literal_value = Value(PrimitiveString::create(vm, static_cast<StringLiteral const&>(initializer).value()));
} else if (is<UnaryExpression>(initializer)) {
auto const& unary = static_cast<UnaryExpression const&>(initializer);
if (unary.op() == UnaryOp::Minus && is<NumericLiteral>(*unary.lhs()))
literal_value = Value(-static_cast<NumericLiteral const&>(*unary.lhs()).value().as_double());
}
if (!literal_value.has_value()) {
// FIXME: For computed-key fields, the field name for anonymous function
// naming is only known at runtime. We use "" here, which means
// e.g. (new (class { [sym] = function(){} }))[sym].name would be
// "" instead of "[sym]". Non-computed keys are handled correctly.
Utf16FlyString field_name;
if (is_private) {
field_name = static_cast<PrivateIdentifier const&>(class_field.key()).string();
} else if (is<Identifier>(class_field.key())) {
field_name = static_cast<Identifier const&>(class_field.key()).string();
} else if (is<StringLiteral>(class_field.key())) {
field_name = Utf16FlyString(static_cast<StringLiteral const&>(class_field.key()).value());
} else if (is<NumericLiteral>(class_field.key())) {
field_name = Utf16FlyString(number_to_utf16_string(static_cast<NumericLiteral const&>(class_field.key()).value().as_double()));
LibJS: Handle BigInt literal keys in class field initializer naming When a class field has a BigInt literal key like `128n = class {}`, the anonymous class should get the name "128". The codegen path handles Identifier, StringLiteral, and NumericLiteral keys but was missing BigInt keys, causing the name to be empty. Parse the BigInt literal value at codegen time and convert it to a decimal string for both the field_name (anonymous function naming) and class_field_initializer_name (eval("arguments") checking) paths.
2026-02-11 19:45:44 +01:00
} else if (is<BigIntLiteral>(class_field.key())) {
field_name = Utf16FlyString::from_utf8(bigint_literal_to_decimal_string(static_cast<BigIntLiteral const&>(class_field.key())));
LibJS: Populate ClassBlueprint during codegen Build a ClassBlueprint from ClassExpression elements at codegen time: - Methods/getters/setters: register SharedFunctionInstanceData from the method's FunctionExpression - Field initializers with literal values (numbers, booleans, null, strings, negated numbers): store the value directly, avoiding function creation entirely - Field initializers with non-literal values: wrap in ClassFieldInitializerStatement and create SharedFunctionInstanceData - Static initializers: create SharedFunctionInstanceData from the function body - Constructor: register SharedFunctionInstanceData from the constructor's FunctionExpression Add public accessors to ClassMethod::function() and StaticInitializer::function_body() for codegen access. The blueprint is registered but not yet used by NewClass (dual path). No behavioral change.
2026-02-11 00:20:47 +01:00
}
auto copy_initializer = class_field.initializer();
auto function_code = create_ast_node<ClassFieldInitializerStatement>(
class_field.initializer()->source_range(),
copy_initializer.release_nonnull(),
move(field_name));
FunctionParsingInsights parsing_insights;
parsing_insights.uses_this_from_environment = true;
parsing_insights.uses_this = true;
auto shared_data = vm.heap().allocate<SharedFunctionInstanceData>(
vm,
FunctionKind::Normal,
"field"_utf16_fly_string,
0,
FunctionParameters::empty(),
*function_code,
Utf16View {},
true,
false,
parsing_insights,
Vector<LocalVariable> {});
LibJS: Wire NewClass to ClassBlueprint Replace the ClassExpression const& reference in the NewClass instruction with a u32 class_blueprint_index. The interpreter now reads from the ClassBlueprint stored on the Executable and calls construct_class() instead of the AST-based create_class_constructor(). Literal field initializers (numbers, booleans, null, strings, negated numbers) are used directly in construct_class() without creating an ECMAScriptFunctionObject, avoiding function creation overhead for common field patterns like `x = 0` or `name = "hello"`. Set class_field_initializer_name on SharedFunctionInstanceData at codegen time for statically-known field keys (identifiers, private identifiers, string literals, and numeric literals). For computed keys, the name is set at runtime in construct_class(). ClassExpression AST nodes are no longer referenced from bytecode.
2026-02-11 00:28:10 +01:00
// Set class_field_initializer_name for keys known at codegen time.
// This is needed so eval("arguments") inside field initializers
// correctly throws a SyntaxError.
if (is_private) {
auto private_name = static_cast<PrivateIdentifier const&>(class_field.key()).string();
shared_data->m_class_field_initializer_name = PrivateName(0, private_name);
} else if (is<Identifier>(class_field.key())) {
auto name = static_cast<Identifier const&>(class_field.key()).string();
shared_data->m_class_field_initializer_name = PropertyKey(name.to_utf16_string());
} else if (is<StringLiteral>(class_field.key())) {
auto name = static_cast<StringLiteral const&>(class_field.key()).value();
shared_data->m_class_field_initializer_name = PropertyKey(name);
} else if (is<NumericLiteral>(class_field.key())) {
auto name = number_to_utf16_string(static_cast<NumericLiteral const&>(class_field.key()).value().as_double());
shared_data->m_class_field_initializer_name = PropertyKey(name);
LibJS: Handle BigInt literal keys in class field initializer naming When a class field has a BigInt literal key like `128n = class {}`, the anonymous class should get the name "128". The codegen path handles Identifier, StringLiteral, and NumericLiteral keys but was missing BigInt keys, causing the name to be empty. Parse the BigInt literal value at codegen time and convert it to a decimal string for both the field_name (anonymous function naming) and class_field_initializer_name (eval("arguments") checking) paths.
2026-02-11 19:45:44 +01:00
} else if (is<BigIntLiteral>(class_field.key())) {
auto name = bigint_literal_to_decimal_string(static_cast<BigIntLiteral const&>(class_field.key()));
shared_data->m_class_field_initializer_name = PropertyKey(Utf16String::from_utf8(name));
LibJS: Wire NewClass to ClassBlueprint Replace the ClassExpression const& reference in the NewClass instruction with a u32 class_blueprint_index. The interpreter now reads from the ClassBlueprint stored on the Executable and calls construct_class() instead of the AST-based create_class_constructor(). Literal field initializers (numbers, booleans, null, strings, negated numbers) are used directly in construct_class() without creating an ECMAScriptFunctionObject, avoiding function creation overhead for common field patterns like `x = 0` or `name = "hello"`. Set class_field_initializer_name on SharedFunctionInstanceData at codegen time for statically-known field keys (identifiers, private identifiers, string literals, and numeric literals). For computed keys, the name is set at runtime in construct_class(). ClassExpression AST nodes are no longer referenced from bytecode.
2026-02-11 00:28:10 +01:00
}
// For computed keys, class_field_initializer_name is set at runtime
// in construct_class().
LibJS: Populate ClassBlueprint during codegen Build a ClassBlueprint from ClassExpression elements at codegen time: - Methods/getters/setters: register SharedFunctionInstanceData from the method's FunctionExpression - Field initializers with literal values (numbers, booleans, null, strings, negated numbers): store the value directly, avoiding function creation entirely - Field initializers with non-literal values: wrap in ClassFieldInitializerStatement and create SharedFunctionInstanceData - Static initializers: create SharedFunctionInstanceData from the function body - Constructor: register SharedFunctionInstanceData from the constructor's FunctionExpression Add public accessors to ClassMethod::function() and StaticInitializer::function_body() for codegen access. The blueprint is registered but not yet used by NewClass (dual path). No behavioral change.
2026-02-11 00:20:47 +01:00
data_index = generator.register_shared_function_data(shared_data);
}
}
blueprint.elements.append({
.kind = ClassElementDescriptor::Kind::Field,
.is_static = element->is_static(),
.is_private = is_private,
.private_identifier = is_private ? Optional<Utf16FlyString>(static_cast<PrivateIdentifier const&>(class_field.key()).string()) : Optional<Utf16FlyString>(),
.shared_function_data_index = data_index,
.has_initializer = has_initializer,
.literal_value = literal_value,
});
} else if (is<StaticInitializer>(*element)) {
auto const& static_init = static_cast<StaticInitializer const&>(*element);
FunctionParsingInsights parsing_insights;
parsing_insights.uses_this_from_environment = true;
parsing_insights.uses_this = true;
auto shared_data = vm.heap().allocate<SharedFunctionInstanceData>(
vm,
FunctionKind::Normal,
Utf16FlyString {},
0,
FunctionParameters::empty(),
static_init.function_body(),
Utf16View {},
true,
false,
parsing_insights,
static_init.function_body().local_variables_names());
auto data_index = generator.register_shared_function_data(shared_data);
blueprint.elements.append({
.kind = ClassElementDescriptor::Kind::StaticInitializer,
.is_static = true,
.is_private = false,
.private_identifier = {},
.shared_function_data_index = data_index,
.has_initializer = false,
.literal_value = {},
});
}
}
auto blueprint_index = generator.register_class_blueprint(move(blueprint));
LibJS: Replace implicit environment stack with explicit registers Replace the saved_lexical_environments stack in ExecutionContextRareData with explicit register-based environment tracking. Environments are now stored in registers and restored via SetLexicalEnvironment, making the environment flow visible in bytecode. Key changes: - Add GetLexicalEnvironment and SetLexicalEnvironment opcodes - CreateLexicalEnvironment takes explicit parent and dst operands - EnterObjectEnvironment stores new environment in a dst register - NewClass takes an explicit class_environment operand - Remove LeaveLexicalEnvironment opcode (instead: SetLexicalEnvironment) - Remove saved_lexical_environments from ExecutionContextRareData - Use a reserved register for the saved lexical environment to avoid dominance issues with lazily-emitted GetLexicalEnvironment
2026-02-09 03:34:42 +01:00
// Restore parent environment before emitting NewClass.
generator.emit<Bytecode::Op::SetLexicalEnvironment>(parent_environment);
generator.pop_lexical_environment_register();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
auto dst = choose_dst(generator, preferred_dst);
LibJS: Wire NewClass to ClassBlueprint Replace the ClassExpression const& reference in the NewClass instruction with a u32 class_blueprint_index. The interpreter now reads from the ClassBlueprint stored on the Executable and calls construct_class() instead of the AST-based create_class_constructor(). Literal field initializers (numbers, booleans, null, strings, negated numbers) are used directly in construct_class() without creating an ECMAScriptFunctionObject, avoiding function creation overhead for common field patterns like `x = 0` or `name = "hello"`. Set class_field_initializer_name on SharedFunctionInstanceData at codegen time for statically-known field keys (identifiers, private identifiers, string literals, and numeric literals). For computed keys, the name is set at runtime in construct_class(). ClassExpression AST nodes are no longer referenced from bytecode.
2026-02-11 00:28:10 +01:00
generator.emit_with_extra_slots<Op::NewClass, Optional<Operand>>(elements.size(), dst, super_class.has_value() ? super_class->operand() : Optional<Operand> {}, class_environment, blueprint_index, lhs_name, elements);
LibJS: Stop using execute_ast_node() for class property evaluation Instead, generate bytecode to execute their AST nodes and save the resulting operands inside the NewClass instruction. Moving property expression evaluation to happen before NewClass execution also moves along creation of new private environment and its population with private members (private members should be visible during property evaluation). Before: - NewClass After: - CreatePrivateEnvironment - AddPrivateName - ... - AddPrivateName - NewClass - LeavePrivateEnvironment
2024-05-11 22:54:41 +00:00
LibJS: Skip PrivateEnvironment allocation if possible If class doesn't have any private fields, we could avoid allocating PrivateEnvironment for it. This allows us to skip thousands of unnecessary PrivateEnvironment allocations on Discord.
2025-07-30 12:10:17 +02:00
if (did_emit_private_environment_allocation) {
generator.emit<Op::LeavePrivateEnvironment>();
}
LibJS: Stop using execute_ast_node in NewClass instruction This change replaces usage of `execute_ast_node` to evaluate super expression in NewClass by generating instructions instead.
2023-06-28 18:22:27 +03:00
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return dst;
LibJS: NewClass bytecode instruction This adds a the NewClass bytecode instruction, enough of it is implemented for it to show it in the bytecode (js -d).
2021-06-30 15:42:13 -03:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> ClassExpression::generate_bytecode(Bytecode::Generator& generator, Optional<ScopedOperand> preferred_dst) const
LibJS/Bytecode: Add codegen for "named evaluation if anonymous function" This gives anonymous functions the name from the LHS they are being assigned to. 171 new passes on test262. :^)
2023-06-23 14:27:42 +02:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return generate_bytecode_with_lhs_name(generator, {}, preferred_dst);
LibJS/Bytecode: Add codegen for "named evaluation if anonymous function" This gives anonymous functions the name from the LHS they are being assigned to. 171 new passes on test262. :^)
2023-06-23 14:27:42 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> SpreadExpression::generate_bytecode(Bytecode::Generator& generator, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS: Allow SpreadExpressions to generate bytecode
2022-09-02 23:39:04 +02:00
{
// NOTE: All users of this should handle the behaviour of this on their own,
// assuming it returns an Array-like object
return m_target->generate_bytecode(generator);
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> ThisExpression::generate_bytecode(Bytecode::Generator& generator, Optional<ScopedOperand> preferred_dst) const
LibJS: Implement 'this' in the bytecode VM ThisExpression now emits a "ResolveThisBinding" bytecode op, which simply loads the VM's current 'this' binding into the accumulator.
2021-10-24 14:43:00 +02:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS/Bytecode: Only emit ResolveThisBinding once per basic block Once executed, this instruction will always produce the same result in subsequent executions, so it's okay to cache it. Unfortunately it may throw, so we can't just hoist it to the top of every executable, since that would break observable execution order.
2024-05-07 12:16:37 +02:00
return generator.get_this(preferred_dst);
LibJS: Implement 'this' in the bytecode VM ThisExpression now emits a "ResolveThisBinding" bytecode op, which simply loads the VM's current 'this' binding into the accumulator.
2021-10-24 14:43:00 +02:00
}
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
static ScopedOperand generate_await(
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
Bytecode::Generator& generator,
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
ScopedOperand argument,
ScopedOperand received_completion,
ScopedOperand received_completion_type,
LibJS: Make async functions & generators faster with helper types Instead of returning internal generator results as ordinary JS::Objects with properties, we now use GeneratorResult and CompletionCell which both inherit from Cell directly and allow efficient access to state. 1.59x speedup on JetStream3/lazy-collections.js :^)
2025-03-31 09:32:39 +01:00
ScopedOperand received_completion_value)
LibJS: Implement async functions as generator functions in BC mode This applies a simple transformation, and adds a simple wrapper that translates the generator interface to the async function interface.
2021-11-11 00:46:07 +03:30
{
VERIFY(generator.is_in_async_function());
auto& continuation_block = generator.make_block();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::Await>(Bytecode::Label { continuation_block }, argument);
LibJS: Implement async functions as generator functions in BC mode This applies a simple transformation, and adds a simple wrapper that translates the generator interface to the async function interface.
2021-11-11 00:46:07 +03:30
generator.switch_to_basic_block(continuation_block);
LibJS: Align codegen AwaitExpressions to YieldExpressions We use generators in bytecode to approximate async functions, but the code generated by AwaitExpressions did not have the value processing paths that Yield requires, eg the `generator.throw()` path, which is used by AsyncFunctionDriverWrapper to signal Promise rejections.
2022-12-25 17:15:29 +01:00
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
// FIXME: It's really magical that we can just assume that the completion value is in register 0.
// It ends up there because we "return" from the Await instruction above via the synthetic
// generator function that actually drives async execution.
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(received_completion, generator.accumulator());
LibJS: Make async functions & generators faster with helper types Instead of returning internal generator results as ordinary JS::Objects with properties, we now use GeneratorResult and CompletionCell which both inherit from Cell directly and allow efficient access to state. 1.59x speedup on JetStream3/lazy-collections.js :^)
2025-03-31 09:32:39 +01:00
get_received_completion_type_and_value(generator, received_completion, received_completion_type, received_completion_value);
LibJS: Align codegen AwaitExpressions to YieldExpressions We use generators in bytecode to approximate async functions, but the code generated by AwaitExpressions did not have the value processing paths that Yield requires, eg the `generator.throw()` path, which is used by AsyncFunctionDriverWrapper to signal Promise rejections.
2022-12-25 17:15:29 +01:00
auto& normal_completion_continuation_block = generator.make_block();
auto& throw_value_block = generator.make_block();
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto received_completion_type_is_normal = generator.allocate_register();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::StrictlyEquals>(
received_completion_type_is_normal,
received_completion_type,
generator.add_constant(Value(to_underlying(Completion::Type::Normal))));
LibJS/Bytecode: Do basic compare-and-jump peephole optimization We now fuse sequences like [LessThan, JumpIf] to JumpLessThan. This is only allowed for temporaries (i.e VM registers) with no other references to them.
2024-05-09 15:13:31 +02:00
generator.emit_jump_if(
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
received_completion_type_is_normal,
LibJS: Align codegen AwaitExpressions to YieldExpressions We use generators in bytecode to approximate async functions, but the code generated by AwaitExpressions did not have the value processing paths that Yield requires, eg the `generator.throw()` path, which is used by AsyncFunctionDriverWrapper to signal Promise rejections.
2022-12-25 17:15:29 +01:00
Bytecode::Label { normal_completion_continuation_block },
Bytecode::Label { throw_value_block });
LibJS/Bytecode: Implement async generators
2023-07-14 21:57:49 +01:00
// Simplification: The only abrupt completion we receive from AsyncFunctionDriverWrapper or AsyncGenerator is Type::Throw
LibJS: Align codegen AwaitExpressions to YieldExpressions We use generators in bytecode to approximate async functions, but the code generated by AwaitExpressions did not have the value processing paths that Yield requires, eg the `generator.throw()` path, which is used by AsyncFunctionDriverWrapper to signal Promise rejections.
2022-12-25 17:15:29 +01:00
// So we do not need to account for the Type::Return path
generator.switch_to_basic_block(throw_value_block);
generator.perform_needed_unwinds<Bytecode::Op::Throw>();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::Throw>(received_completion_value);
LibJS: Align codegen AwaitExpressions to YieldExpressions We use generators in bytecode to approximate async functions, but the code generated by AwaitExpressions did not have the value processing paths that Yield requires, eg the `generator.throw()` path, which is used by AsyncFunctionDriverWrapper to signal Promise rejections.
2022-12-25 17:15:29 +01:00
generator.switch_to_basic_block(normal_completion_continuation_block);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return received_completion_value;
LibJS/Bytecode: Implement for await of Summary: Diff Tests: +391 ✅ +15 ❌ +2 💥️ -408 📝
2023-06-27 19:24:34 +01:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> AwaitExpression::generate_bytecode(Bytecode::Generator& generator, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS/Bytecode: Implement for await of Summary: Diff Tests: +391 ✅ +15 ❌ +2 💥️ -408 📝
2023-06-27 19:24:34 +01:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto argument = m_argument->generate_bytecode(generator).value();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto received_completion = generator.allocate_register();
auto received_completion_type = generator.allocate_register();
auto received_completion_value = generator.allocate_register();
LibJS/Bytecode: Implement async generators
2023-07-14 21:57:49 +01:00
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(received_completion, generator.accumulator());
LibJS/Bytecode: Implement async generators
2023-07-14 21:57:49 +01:00
LibJS: Make async functions & generators faster with helper types Instead of returning internal generator results as ordinary JS::Objects with properties, we now use GeneratorResult and CompletionCell which both inherit from Cell directly and allow efficient access to state. 1.59x speedup on JetStream3/lazy-collections.js :^)
2025-03-31 09:32:39 +01:00
return generate_await(generator, argument, received_completion, received_completion_type, received_completion_value);
LibJS: Implement async functions as generator functions in BC mode This applies a simple transformation, and adds a simple wrapper that translates the generator interface to the async function interface.
2021-11-11 00:46:07 +03:30
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> WithStatement::generate_bytecode(Bytecode::Generator& generator, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS: Implement bytecode generation for WithStatement
2022-03-13 16:01:18 +03:30
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto object = m_object->generate_bytecode(generator).value();
LibJS: Replace implicit environment stack with explicit registers Replace the saved_lexical_environments stack in ExecutionContextRareData with explicit register-based environment tracking. Environments are now stored in registers and restored via SetLexicalEnvironment, making the environment flow visible in bytecode. Key changes: - Add GetLexicalEnvironment and SetLexicalEnvironment opcodes - CreateLexicalEnvironment takes explicit parent and dst operands - EnterObjectEnvironment stores new environment in a dst register - NewClass takes an explicit class_environment operand - Remove LeaveLexicalEnvironment opcode (instead: SetLexicalEnvironment) - Remove saved_lexical_environments from ExecutionContextRareData - Use a reserved register for the saved lexical environment to avoid dominance issues with lazily-emitted GetLexicalEnvironment
2026-02-09 03:34:42 +01:00
auto object_environment = generator.allocate_register();
generator.emit<Bytecode::Op::EnterObjectEnvironment>(object_environment, object);
generator.push_lexical_environment_register(object_environment);
LibJS/Bytecode: Setup lexical environment boundary for with statements This allows us to properly unwind the object environment for `with` on a block terminating instruction, e.g. an unconditional throw.
2022-03-14 02:35:45 +00:00
// EnterObjectEnvironment sets the running execution context's lexical_environment to a new Object Environment.
generator.start_boundary(Bytecode::Generator::BlockBoundaryType::LeaveLexicalEnvironment);
LibJS/Bytecode: Make sure empty `with` statement results in `undefined` 2 new passes on test262. :^)
2023-07-02 10:28:36 +02:00
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto body_result = m_body->generate_bytecode(generator);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
if (!body_result.has_value())
body_result = generator.add_constant(js_undefined());
LibJS/Bytecode: Setup lexical environment boundary for with statements This allows us to properly unwind the object environment for `with` on a block terminating instruction, e.g. an unconditional throw.
2022-03-14 02:35:45 +00:00
generator.end_boundary(Bytecode::Generator::BlockBoundaryType::LeaveLexicalEnvironment);
LibJS: Replace implicit environment stack with explicit registers Replace the saved_lexical_environments stack in ExecutionContextRareData with explicit register-based environment tracking. Environments are now stored in registers and restored via SetLexicalEnvironment, making the environment flow visible in bytecode. Key changes: - Add GetLexicalEnvironment and SetLexicalEnvironment opcodes - CreateLexicalEnvironment takes explicit parent and dst operands - EnterObjectEnvironment stores new environment in a dst register - NewClass takes an explicit class_environment operand - Remove LeaveLexicalEnvironment opcode (instead: SetLexicalEnvironment) - Remove saved_lexical_environments from ExecutionContextRareData - Use a reserved register for the saved lexical environment to avoid dominance issues with lazily-emitted GetLexicalEnvironment
2026-02-09 03:34:42 +01:00
generator.pop_lexical_environment_register();
LibJS/Bytecode: Setup lexical environment boundary for with statements This allows us to properly unwind the object environment for `with` on a block terminating instruction, e.g. an unconditional throw.
2022-03-14 02:35:45 +00:00
if (!generator.is_current_block_terminated())
LibJS: Replace implicit environment stack with explicit registers Replace the saved_lexical_environments stack in ExecutionContextRareData with explicit register-based environment tracking. Environments are now stored in registers and restored via SetLexicalEnvironment, making the environment flow visible in bytecode. Key changes: - Add GetLexicalEnvironment and SetLexicalEnvironment opcodes - CreateLexicalEnvironment takes explicit parent and dst operands - EnterObjectEnvironment stores new environment in a dst register - NewClass takes an explicit class_environment operand - Remove LeaveLexicalEnvironment opcode (instead: SetLexicalEnvironment) - Remove saved_lexical_environments from ExecutionContextRareData - Use a reserved register for the saved lexical environment to avoid dominance issues with lazily-emitted GetLexicalEnvironment
2026-02-09 03:34:42 +01:00
generator.emit<Bytecode::Op::SetLexicalEnvironment>(generator.current_lexical_environment_register());
LibJS/Bytecode: Setup lexical environment boundary for with statements This allows us to properly unwind the object environment for `with` on a block terminating instruction, e.g. an unconditional throw.
2022-03-14 02:35:45 +00:00
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return body_result;
LibJS: Implement bytecode generation for WithStatement
2022-03-13 16:01:18 +03:30
}
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
enum class LHSKind {
Assignment,
VarBinding,
LexicalBinding,
};
enum class IterationKind {
Enumerate,
Iterate,
AsyncIterate,
};
// 14.7.5.6 ForIn/OfHeadEvaluation ( uninitializedBoundNames, expr, iterationKind ), https://tc39.es/ecma262/#sec-runtime-semantics-forinofheadevaluation
struct ForInOfHeadEvaluationResult {
bool is_destructuring { false };
LHSKind lhs_kind { LHSKind::Assignment };
LibJS: Avoid `IteratorRecord` GC-allocation in `GetIterator` instruction With this change, `GetIterator` no longer GC-allocates an `IteratorRecord`. Instead, it stores the iterator record fields in bytecode registers. This avoids per-iteration allocations in patterns like: `for (let [x] of array) {}`. `IteratorRecord` now inherits from `IteratorRecordImpl`, which holds the iteration state. This allows the existing iteration helpers (`iterator_next()`, `iterator_step()`, etc.) operate on both the GC-allocated and the register-backed forms. Microbenchmarks: 1.1x array-destructuring-assignment-rest.js 1.226x array-destructuring-assignment.js
2025-10-27 19:46:54 +01:00
Optional<ScopedOperand> iterator_object;
Optional<ScopedOperand> iterator_next_method;
Optional<ScopedOperand> iterator_done_property;
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
};
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
static ForInOfHeadEvaluationResult for_in_of_head_evaluation(Bytecode::Generator& generator, IterationKind iteration_kind, Variant<NonnullRefPtr<ASTNode const>, NonnullRefPtr<BindingPattern const>> const& lhs, NonnullRefPtr<ASTNode const> const& rhs)
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
{
ForInOfHeadEvaluationResult result {};
LibJS: Support `for (x in obj)` iteration in bytecode VM We were mistakenly treating these as `for (x of obj)`. By reorganizing the code a little bit, we actually support both kinds of iteration with less duplication. :^) Fixes 17 tests in test262.
2022-10-19 17:42:54 +02:00
bool entered_lexical_scope = false;
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
if (auto* ast_ptr = lhs.get_pointer<NonnullRefPtr<ASTNode const>>(); ast_ptr && is<VariableDeclaration>(**ast_ptr)) {
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
// Runtime Semantics: ForInOfLoopEvaluation, for any of:
// ForInOfStatement : for ( var ForBinding in Expression ) Statement
// ForInOfStatement : for ( ForDeclaration in Expression ) Statement
// ForInOfStatement : for ( var ForBinding of AssignmentExpression ) Statement
// ForInOfStatement : for ( ForDeclaration of AssignmentExpression ) Statement
auto& variable_declaration = static_cast<VariableDeclaration const&>(**ast_ptr);
Everywhere: Stop using NonnullRefPtrVector This class had slightly confusing semantics and the added weirdness doesn't seem worth it just so we can say "." instead of "->" when iterating over a vector of NNRPs. This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
2023-03-06 14:17:01 +01:00
result.is_destructuring = variable_declaration.declarations().first()->target().has<NonnullRefPtr<BindingPattern const>>();
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
result.lhs_kind = variable_declaration.is_lexical_declaration() ? LHSKind::LexicalBinding : LHSKind::VarBinding;
LibJS/Bytecode: Implement Annex B Initializers in ForIn Statement Heads
2023-06-28 09:07:33 +02:00
if (variable_declaration.declaration_kind() == DeclarationKind::Var) {
// B.3.5 Initializers in ForIn Statement Heads, https://tc39.es/ecma262/#sec-initializers-in-forin-statement-heads
auto& variable = variable_declaration.declarations().first();
if (variable->init()) {
VERIFY(variable->target().has<NonnullRefPtr<Identifier const>>());
LibJS: Update bytecode generator to use local variables - Update ECMAScriptFunctionObject::function_declaration_instantiation to initialize local variables - Introduce GetLocal, SetLocal, TypeofLocal that will be used to operate on local variables. - Update bytecode generator to emit instructions for local variables
2023-07-05 02:17:10 +02:00
auto identifier = variable->target().get<NonnullRefPtr<Identifier const>>();
auto identifier_table_ref = generator.intern_identifier(identifier->string());
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto value = generator.emit_named_evaluation_if_anonymous_function(*variable->init(), identifier_table_ref);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit_set_variable(*identifier, value);
LibJS/Bytecode: Implement Annex B Initializers in ForIn Statement Heads
2023-06-28 09:07:33 +02:00
}
} else {
LibJS/Bytecode: Skip CreateVariable for locals in "for" loop head CreateVariable is not needed for locals because they are not stored in environment and created binding will not be used. Also if all variables in loop initialization sections are local then CreateLexicalEnvironment and LeaveLexicalEnvironment can also be ommitted.
2023-07-13 21:30:36 +02:00
auto has_non_local_variables = false;
MUST(variable_declaration.for_each_bound_identifier([&](auto const& identifier) {
if (!identifier.is_local())
has_non_local_variables = true;
LibJS: Don't discard ThrowCompletionOr<void> from declaration iteration
2023-02-27 22:13:37 +00:00
}));
LibJS/Bytecode: Skip CreateVariable for locals in "for" loop head CreateVariable is not needed for locals because they are not stored in environment and created binding will not be used. Also if all variables in loop initialization sections are local then CreateLexicalEnvironment and LeaveLexicalEnvironment can also be ommitted.
2023-07-13 21:30:36 +02:00
if (has_non_local_variables) {
// 1. Let oldEnv be the running execution context's LexicalEnvironment.
// NOTE: 'uninitializedBoundNames' refers to the lexical bindings (i.e. Const/Let) present in the second and last form.
// 2. If uninitializedBoundNames is not an empty List, then
entered_lexical_scope = true;
// a. Assert: uninitializedBoundNames has no duplicate entries.
// b. Let newEnv be NewDeclarativeEnvironment(oldEnv).
generator.begin_variable_scope();
// c. For each String name of uninitializedBoundNames, do
// NOTE: Nothing in the callback throws an exception.
MUST(variable_declaration.for_each_bound_identifier([&](auto const& identifier) {
if (identifier.is_local())
return;
// i. Perform ! newEnv.CreateMutableBinding(name, false).
auto interned_identifier = generator.intern_identifier(identifier.string());
LibJS: Generate C++ bytecode instruction classes from a definition file This commit adds a new Bytecode.def file that describes all the LibJS bytecode instructions. From this, we are able to generate the full declarations for all C++ bytecode instruction classes, as well as their serialization code. Note that some of the bytecode compiler was updated since instructions no longer have default constructor arguments. The big immediate benefit here is that we lose a couple thousand lines of hand-written C++ code. Going forward, this also allows us to do more tooling for the bytecode VM, now that we have an authoritative description of its instructions. Key things to know about: - Instructions can inherit from one another. At the moment, everything simply inherits from the base "Instruction". - @terminator means the instruction terminates a basic block. - @nothrow means the instruction cannot throw. This affects how the interpreter interacts with it. - Variable-length instructions are automatically supported. Just put an array of something as the last field of the instruction. - The m_length field is magical. If present, it will be populated with the full length of the instruction. This is used for variable-length instructions.
2025-11-20 22:14:50 +01:00
generator.emit<Bytecode::Op::CreateVariable>(interned_identifier, Bytecode::Op::EnvironmentMode::Lexical, false, false, false);
LibJS/Bytecode: Skip CreateVariable for locals in "for" loop head CreateVariable is not needed for locals because they are not stored in environment and created binding will not be used. Also if all variables in loop initialization sections are local then CreateLexicalEnvironment and LeaveLexicalEnvironment can also be ommitted.
2023-07-13 21:30:36 +02:00
}));
// d. Set the running execution context's LexicalEnvironment to newEnv.
// NOTE: Done by CreateLexicalEnvironment.
}
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
}
} else {
// Runtime Semantics: ForInOfLoopEvaluation, for any of:
// ForInOfStatement : for ( LeftHandSideExpression in Expression ) Statement
// ForInOfStatement : for ( LeftHandSideExpression of AssignmentExpression ) Statement
result.lhs_kind = LHSKind::Assignment;
LibJS: Support `for (x in obj)` iteration in bytecode VM We were mistakenly treating these as `for (x of obj)`. By reorganizing the code a little bit, we actually support both kinds of iteration with less duplication. :^) Fixes 17 tests in test262.
2022-10-19 17:42:54 +02:00
}
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
LibJS: Support `for (x in obj)` iteration in bytecode VM We were mistakenly treating these as `for (x of obj)`. By reorganizing the code a little bit, we actually support both kinds of iteration with less duplication. :^) Fixes 17 tests in test262.
2022-10-19 17:42:54 +02:00
// 3. Let exprRef be the result of evaluating expr.
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto object = rhs->generate_bytecode(generator).value();
LibJS: Support `for (x in obj)` iteration in bytecode VM We were mistakenly treating these as `for (x of obj)`. By reorganizing the code a little bit, we actually support both kinds of iteration with less duplication. :^) Fixes 17 tests in test262.
2022-10-19 17:42:54 +02:00
// 4. Set the running execution context's LexicalEnvironment to oldEnv.
if (entered_lexical_scope)
generator.end_variable_scope();
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
LibJS: Support `for (x in obj)` iteration in bytecode VM We were mistakenly treating these as `for (x of obj)`. By reorganizing the code a little bit, we actually support both kinds of iteration with less duplication. :^) Fixes 17 tests in test262.
2022-10-19 17:42:54 +02:00
// 5. Let exprValue be ? GetValue(exprRef).
// NOTE: No need to store this anywhere.
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
LibJS: Avoid `IteratorRecord` GC-allocation in `GetIterator` instruction With this change, `GetIterator` no longer GC-allocates an `IteratorRecord`. Instead, it stores the iterator record fields in bytecode registers. This avoids per-iteration allocations in patterns like: `for (let [x] of array) {}`. `IteratorRecord` now inherits from `IteratorRecordImpl`, which holds the iteration state. This allows the existing iteration helpers (`iterator_next()`, `iterator_step()`, etc.) operate on both the GC-allocated and the register-backed forms. Microbenchmarks: 1.1x array-destructuring-assignment-rest.js 1.226x array-destructuring-assignment.js
2025-10-27 19:46:54 +01:00
auto iterator_object = generator.allocate_register();
auto iterator_next_method = generator.allocate_register();
auto iterator_done_property = generator.allocate_register();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
LibJS: Support `for (x in obj)` iteration in bytecode VM We were mistakenly treating these as `for (x of obj)`. By reorganizing the code a little bit, we actually support both kinds of iteration with less duplication. :^) Fixes 17 tests in test262.
2022-10-19 17:42:54 +02:00
// 6. If iterationKind is enumerate, then
if (iteration_kind == IterationKind::Enumerate) {
// a. If exprValue is undefined or null, then
auto& nullish_block = generator.make_block();
auto& continuation_block = generator.make_block();
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
generator.emit<Bytecode::Op::JumpNullish>(
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
object,
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
Bytecode::Label { nullish_block },
Bytecode::Label { continuation_block });
LibJS: Support `for (x in obj)` iteration in bytecode VM We were mistakenly treating these as `for (x of obj)`. By reorganizing the code a little bit, we actually support both kinds of iteration with less duplication. :^) Fixes 17 tests in test262.
2022-10-19 17:42:54 +02:00
// i. Return Completion Record { [[Type]]: break, [[Value]]: empty, [[Target]]: empty }.
generator.switch_to_basic_block(nullish_block);
LibJS: Simplify `Generator::perform_needed_unwinds` This does not need to cater to the needs of `break` and `continue anymore, which allows us to simplify it a bit.
2022-11-25 16:42:29 +01:00
generator.generate_break();
LibJS: Support `for (x in obj)` iteration in bytecode VM We were mistakenly treating these as `for (x of obj)`. By reorganizing the code a little bit, we actually support both kinds of iteration with less duplication. :^) Fixes 17 tests in test262.
2022-10-19 17:42:54 +02:00
generator.switch_to_basic_block(continuation_block);
// b. Let obj be ! ToObject(exprValue).
// NOTE: GetObjectPropertyIterator does this.
// c. Let iterator be EnumerateObjectProperties(obj).
// d. Let nextMethod be ! GetV(iterator, "next").
// e. Return the Iterator Record { [[Iterator]]: iterator, [[NextMethod]]: nextMethod, [[Done]]: false }.
LibJS: Avoid `IteratorRecord` GC-allocation in `GetIterator` instruction With this change, `GetIterator` no longer GC-allocates an `IteratorRecord`. Instead, it stores the iterator record fields in bytecode registers. This avoids per-iteration allocations in patterns like: `for (let [x] of array) {}`. `IteratorRecord` now inherits from `IteratorRecordImpl`, which holds the iteration state. This allows the existing iteration helpers (`iterator_next()`, `iterator_step()`, etc.) operate on both the GC-allocated and the register-backed forms. Microbenchmarks: 1.1x array-destructuring-assignment-rest.js 1.226x array-destructuring-assignment.js
2025-10-27 19:46:54 +01:00
generator.emit<Bytecode::Op::GetObjectPropertyIterator>(iterator_object, iterator_next_method, iterator_done_property, object);
LibJS: Support `for (x in obj)` iteration in bytecode VM We were mistakenly treating these as `for (x of obj)`. By reorganizing the code a little bit, we actually support both kinds of iteration with less duplication. :^) Fixes 17 tests in test262.
2022-10-19 17:42:54 +02:00
}
// 7. Else,
else {
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
// a. Assert: iterationKind is iterate or async-iterate.
LibJS: Make GetIterator's hint parameter required This is an editorial change in the ECMA-262 spec. See: https://github.com/tc39/ecma262/commit/2562811
2023-07-18 14:52:21 -04:00
// b. If iterationKind is async-iterate, let iteratorKind be async.
// c. Else, let iteratorKind be sync.
auto iterator_kind = iteration_kind == IterationKind::AsyncIterate ? IteratorHint::Async : IteratorHint::Sync;
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
LibJS: Make GetIterator's hint parameter required This is an editorial change in the ECMA-262 spec. See: https://github.com/tc39/ecma262/commit/2562811
2023-07-18 14:52:21 -04:00
// d. Return ? GetIterator(exprValue, iteratorKind).
LibJS: Avoid `IteratorRecord` GC-allocation in `GetIterator` instruction With this change, `GetIterator` no longer GC-allocates an `IteratorRecord`. Instead, it stores the iterator record fields in bytecode registers. This avoids per-iteration allocations in patterns like: `for (let [x] of array) {}`. `IteratorRecord` now inherits from `IteratorRecordImpl`, which holds the iteration state. This allows the existing iteration helpers (`iterator_next()`, `iterator_step()`, etc.) operate on both the GC-allocated and the register-backed forms. Microbenchmarks: 1.1x array-destructuring-assignment-rest.js 1.226x array-destructuring-assignment.js
2025-10-27 19:46:54 +01:00
generator.emit<Bytecode::Op::GetIterator>(iterator_object, iterator_next_method, iterator_done_property, object, iterator_kind);
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
}
LibJS: Avoid `IteratorRecord` GC-allocation in `GetIterator` instruction With this change, `GetIterator` no longer GC-allocates an `IteratorRecord`. Instead, it stores the iterator record fields in bytecode registers. This avoids per-iteration allocations in patterns like: `for (let [x] of array) {}`. `IteratorRecord` now inherits from `IteratorRecordImpl`, which holds the iteration state. This allows the existing iteration helpers (`iterator_next()`, `iterator_step()`, etc.) operate on both the GC-allocated and the register-backed forms. Microbenchmarks: 1.1x array-destructuring-assignment-rest.js 1.226x array-destructuring-assignment.js
2025-10-27 19:46:54 +01:00
result.iterator_object = iterator_object;
result.iterator_next_method = iterator_next_method;
result.iterator_done_property = iterator_done_property;
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
return result;
}
// 14.7.5.7 ForIn/OfBodyEvaluation ( lhs, stmt, iteratorRecord, iterationKind, lhsKind, labelSet [ , iteratorKind ] ), https://tc39.es/ecma262/#sec-runtime-semantics-forin-div-ofbodyevaluation-lhs-stmt-iterator-lhskind-labelset
LibJS: Call IteratorClose on abrupt completion in for-of loops When a for-of or for-await-of loop exits via break, return, throw, or continue-to-outer-loop, we now correctly call IteratorClose (or AsyncIteratorClose) to give the iterator a chance to clean up resources. This uses a synthetic FinallyContext that wraps the LHS assignment and loop body, reusing the existing try/finally completion record machinery. The ReturnToFinally boundary is placed between Break and Continue so that continue-to-same-loop bypasses the close (zero overhead on normal iteration) while all other abrupt exits route through the iterator close dispatch chain. for-in (enumerate) does not require iterator close per spec.
2026-02-11 23:49:53 +01:00
static Optional<ScopedOperand> for_in_of_body_evaluation(Bytecode::Generator& generator, Variant<NonnullRefPtr<ASTNode const>, NonnullRefPtr<BindingPattern const>> const& lhs, ASTNode const& body, ForInOfHeadEvaluationResult const& head_result, IterationKind iteration_kind, Vector<FlyString> const& label_set, Bytecode::BasicBlock& loop_end, Bytecode::BasicBlock& loop_update, IteratorHint iterator_kind = IteratorHint::Sync, [[maybe_unused]] Optional<ScopedOperand> preferred_dst = {})
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
{
LibJS/Bytecode: Implement for await of Summary: Diff Tests: +391 ✅ +15 ❌ +2 💥️ -408 📝
2023-06-27 19:24:34 +01:00
// 1. If iteratorKind is not present, set iteratorKind to sync.
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
// 2. Let oldEnv be the running execution context's LexicalEnvironment.
bool has_lexical_binding = false;
// 3. Let V be undefined.
LibJS/Bytecode: Don't bother propagating completion values in functions The last completion value in a function is not exposed to the language, since functions always either return something, or undefined. Given this, we can avoid emitting code that propagates the completion value from various statements, as long as we know we're generating code for a context where the completion value is not accessible. In practical terms, this means that function code gets to do less completion shuffling, while global and eval code has to keep doing it.
2024-05-14 10:57:06 +02:00
Optional<ScopedOperand> completion;
if (generator.must_propagate_completion()) {
completion = generator.allocate_register();
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(*completion, generator.add_constant(js_undefined()));
LibJS/Bytecode: Don't bother propagating completion values in functions The last completion value in a function is not exposed to the language, since functions always either return something, or undefined. Given this, we can avoid emitting code that propagates the completion value from various statements, as long as we know we're generating code for a context where the completion value is not accessible. In practical terms, this means that function code gets to do less completion shuffling, while global and eval code has to keep doing it.
2024-05-14 10:57:06 +02:00
}
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
// 4. Let destructuring be IsDestructuring of lhs.
auto destructuring = head_result.is_destructuring;
// 5. If destructuring is true and if lhsKind is assignment, then
LibJS: Convert unreachable codegen error sites to VERIFY Replace CodeGenerationError returns with VERIFY_NOT_REACHED() or VERIFY() at sites that are provably unreachable: - Non-computed member expression fallbacks in emit_load_from_reference, emit_store_to_reference, and emit_delete_reference (member expression properties are always computed, identifier, or private identifier) - Two non-computed member expression fallbacks in AssignmentExpression - Default case in compound assignment switch (all 15 AssignmentOp values are handled) - BindingPattern Empty/Expression name+alias pair (computed property names always require an alias) - Two assignment+destructuring combinations in for-in/of body evaluation (is_destructuring is only set for VariableDeclaration lhs, which always has VarBinding or LexicalBinding kind, never Assignment)
2026-02-11 22:05:55 +01:00
// NB: is_destructuring is only set for VariableDeclaration lhs (which always has lhs_kind
// VarBinding or LexicalBinding), so this combination is unreachable.
VERIFY(!(destructuring && head_result.lhs_kind == LHSKind::Assignment));
LibJS: Fix UpdateEmpty completion value semantics for loops/switch/if When a loop or switch body produces an abrupt completion (break or continue) with an empty value, the ES spec requires UpdateEmpty to replace the empty value with the last non-empty completion value V. The bytecode compiler was failing to do this because it only updated the completion register after body codegen, guarded by !is_current_block_terminated(). When break/continue terminated the block, the update was skipped. Fix this with three changes: 1. Introduce a CompletionRegisterScope that tells ScopeNode::generate_bytecode to eagerly emit Mov instructions into the completion register after each value-producing statement. This ensures the register is up to date before any break or continue fires. 2. Give IfStatement its own CompletionRegisterScope (initialized to undefined) during branch evaluation. This models the spec's UpdateEmpty(stmtCompletion, undefined) for if-statements: when break/continue fires inside an if-branch, the scoped jump propagation sees that the if's completion register differs from the loop's and emits a Mov, correctly replacing the eagerly written value with undefined. Without this, code like { 3; if (true) { break; } else { } } would incorrectly carry the value 3 instead of undefined through the break. 3. Capture loop body results and emit a fallback Mov for non-ScopeNode bodies (e.g. bare expression statements like do x=1; while(false)) that don't participate in the eager CompletionRegisterScope update mechanism. For labelled break/continue that cross loop boundaries, the jump codegen now propagates the inner completion register to the target scope's completion register before emitting the jump. Also fix ForStatement to use a proper completion register (previously it returned the body result directly, which was wrong for empty bodies and break-with-no-value cases).
2026-02-10 23:25:24 +01:00
if (completion.has_value())
generator.set_current_breakable_scope_completion_register(*completion);
LibJS: Call IteratorClose on abrupt completion in for-of loops When a for-of or for-await-of loop exits via break, return, throw, or continue-to-outer-loop, we now correctly call IteratorClose (or AsyncIteratorClose) to give the iterator a chance to clean up resources. This uses a synthetic FinallyContext that wraps the LHS assignment and loop body, reusing the existing try/finally completion record machinery. The ReturnToFinally boundary is placed between Break and Continue so that continue-to-same-loop bypasses the close (zero overhead on normal iteration) while all other abrupt exits route through the iterator close dispatch chain. for-in (enumerate) does not require iterator close per spec.
2026-02-11 23:49:53 +01:00
// For for-of and for-await-of, set up a synthetic FinallyContext so that
// IteratorClose/AsyncIteratorClose is called on abrupt completion (break,
// return, throw, or continue-to-outer-loop). for-in (enumerate) does not
// need iterator close per spec.
bool needs_iterator_close = (iteration_kind != IterationKind::Enumerate);
Optional<Bytecode::Generator::FinallyContext> iterator_close_finally_context;
Optional<Bytecode::Generator::UnwindContext> iterator_close_unwind_context;
Optional<ScopedOperand> close_completion_type;
Optional<ScopedOperand> close_completion_value;
Bytecode::BasicBlock* exception_preamble_block { nullptr };
Bytecode::BasicBlock* iterator_close_body_block { nullptr };
Optional<ScopedOperand> lexical_environment_at_entry;
if (needs_iterator_close) {
lexical_environment_at_entry = generator.current_lexical_environment_register();
close_completion_type = generator.allocate_register();
close_completion_value = generator.allocate_register();
exception_preamble_block = &generator.make_block();
iterator_close_body_block = &generator.make_block();
iterator_close_finally_context.emplace(Bytecode::Generator::FinallyContext {
.completion_type = *close_completion_type,
.completion_value = *close_completion_value,
.finally_body = Bytecode::Label { *iterator_close_body_block },
.exception_preamble = Bytecode::Label { *exception_preamble_block },
.parent = generator.current_finally_context(),
.registered_jumps = {},
.next_jump_index = Bytecode::Generator::FinallyContext::FIRST_JUMP_INDEX,
.lexical_environment_at_entry = lexical_environment_at_entry,
});
generator.set_current_finally_context(&*iterator_close_finally_context);
// Place ReturnToFinally between Break (pushed by caller) and Continue
// (pushed by begin_continuable_scope below). This ensures:
// - continue to this loop: hits Continue first -> direct jump (no close)
// - break/return/throw/continue-to-outer: hits ReturnToFinally -> close
generator.start_boundary(Bytecode::Generator::BlockBoundaryType::ReturnToFinally);
// NB: The UnwindContext (exception handler) is set up later, after
// the iterator-next section. Per spec, exceptions from steps a-f
// (IteratorNext, Await, IteratorComplete, IteratorValue) propagate
// directly without calling IteratorClose. Only exceptions from
// LHS assignment (steps g-j) and the loop body (step l) should
// trigger iterator close.
}
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
// 6. Repeat,
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { loop_update });
generator.switch_to_basic_block(loop_update);
LibJS: Fix UpdateEmpty completion value semantics for loops/switch/if When a loop or switch body produces an abrupt completion (break or continue) with an empty value, the ES spec requires UpdateEmpty to replace the empty value with the last non-empty completion value V. The bytecode compiler was failing to do this because it only updated the completion register after body codegen, guarded by !is_current_block_terminated(). When break/continue terminated the block, the update was skipped. Fix this with three changes: 1. Introduce a CompletionRegisterScope that tells ScopeNode::generate_bytecode to eagerly emit Mov instructions into the completion register after each value-producing statement. This ensures the register is up to date before any break or continue fires. 2. Give IfStatement its own CompletionRegisterScope (initialized to undefined) during branch evaluation. This models the spec's UpdateEmpty(stmtCompletion, undefined) for if-statements: when break/continue fires inside an if-branch, the scoped jump propagation sees that the if's completion register differs from the loop's and emits a Mov, correctly replacing the eagerly written value with undefined. Without this, code like { 3; if (true) { break; } else { } } would incorrectly carry the value 3 instead of undefined through the break. 3. Capture loop body results and emit a fallback Mov for non-ScopeNode bodies (e.g. bare expression statements like do x=1; while(false)) that don't participate in the eager CompletionRegisterScope update mechanism. For labelled break/continue that cross loop boundaries, the jump codegen now propagates the inner completion register to the target scope's completion register before emitting the jump. Also fix ForStatement to use a proper completion register (previously it returned the body result directly, which was wrong for empty bodies and break-with-no-value cases).
2026-02-10 23:25:24 +01:00
generator.begin_continuable_scope(Bytecode::Label { loop_update }, label_set, completion);
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
// a. Let nextResult be ? Call(iteratorRecord.[[NextMethod]], iteratorRecord.[[Iterator]]).
LibJS: Skip iterator result object allocation in for..of and for..in Introduce special instruction for `for..of` and `for..in` loop that skips `{ value, done }` result object allocation if iterator is builtin (array, map, set, string). This reduces GC pressure significantly and avoids extracting the `value` and `done` properties. This change makes this micro benchmark 48% faster on my computer: ```js const arr = new Array(10_000_000); let counter = 0; for (let _ of arr) { counter++; } ```
2025-04-30 16:31:26 +03:00
auto next_value = generator.allocate_register();
auto done = generator.allocate_register();
if (iterator_kind == IteratorHint::Sync) {
LibJS: Avoid `IteratorRecord` GC-allocation in `GetIterator` instruction With this change, `GetIterator` no longer GC-allocates an `IteratorRecord`. Instead, it stores the iterator record fields in bytecode registers. This avoids per-iteration allocations in patterns like: `for (let [x] of array) {}`. `IteratorRecord` now inherits from `IteratorRecordImpl`, which holds the iteration state. This allows the existing iteration helpers (`iterator_next()`, `iterator_step()`, etc.) operate on both the GC-allocated and the register-backed forms. Microbenchmarks: 1.1x array-destructuring-assignment-rest.js 1.226x array-destructuring-assignment.js
2025-10-27 19:46:54 +01:00
generator.emit<Bytecode::Op::IteratorNextUnpack>(next_value, done, *head_result.iterator_object, *head_result.iterator_next_method, *head_result.iterator_done_property);
LibJS: Skip iterator result object allocation in for..of and for..in Introduce special instruction for `for..of` and `for..in` loop that skips `{ value, done }` result object allocation if iterator is builtin (array, map, set, string). This reduces GC pressure significantly and avoids extracting the `value` and `done` properties. This change makes this micro benchmark 48% faster on my computer: ```js const arr = new Array(10_000_000); let counter = 0; for (let _ of arr) { counter++; } ```
2025-04-30 16:31:26 +03:00
auto& loop_continue = generator.make_block();
generator.emit_jump_if(
done,
Bytecode::Label { loop_end },
Bytecode::Label { loop_continue });
generator.switch_to_basic_block(loop_continue);
} else {
auto next_result = generator.allocate_register();
LibJS: Avoid `IteratorRecord` GC-allocation in `GetIterator` instruction With this change, `GetIterator` no longer GC-allocates an `IteratorRecord`. Instead, it stores the iterator record fields in bytecode registers. This avoids per-iteration allocations in patterns like: `for (let [x] of array) {}`. `IteratorRecord` now inherits from `IteratorRecordImpl`, which holds the iteration state. This allows the existing iteration helpers (`iterator_next()`, `iterator_step()`, etc.) operate on both the GC-allocated and the register-backed forms. Microbenchmarks: 1.1x array-destructuring-assignment-rest.js 1.226x array-destructuring-assignment.js
2025-10-27 19:46:54 +01:00
generator.emit<Bytecode::Op::IteratorNext>(next_result, *head_result.iterator_object, *head_result.iterator_next_method, *head_result.iterator_done_property);
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
LibJS: Skip iterator result object allocation in for..of and for..in Introduce special instruction for `for..of` and `for..in` loop that skips `{ value, done }` result object allocation if iterator is builtin (array, map, set, string). This reduces GC pressure significantly and avoids extracting the `value` and `done` properties. This change makes this micro benchmark 48% faster on my computer: ```js const arr = new Array(10_000_000); let counter = 0; for (let _ of arr) { counter++; } ```
2025-04-30 16:31:26 +03:00
// b. If iteratorKind is async, set nextResult to ? Await(nextResult).
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto received_completion = generator.allocate_register();
auto received_completion_type = generator.allocate_register();
auto received_completion_value = generator.allocate_register();
LibJS/Bytecode: Implement async generators
2023-07-14 21:57:49 +01:00
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(received_completion, generator.accumulator());
LibJS: Make async functions & generators faster with helper types Instead of returning internal generator results as ordinary JS::Objects with properties, we now use GeneratorResult and CompletionCell which both inherit from Cell directly and allow efficient access to state. 1.59x speedup on JetStream3/lazy-collections.js :^)
2025-03-31 09:32:39 +01:00
auto new_result = generate_await(generator, next_result, received_completion, received_completion_type, received_completion_value);
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(next_result, new_result);
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
LibJS: Skip iterator result object allocation in for..of and for..in Introduce special instruction for `for..of` and `for..in` loop that skips `{ value, done }` result object allocation if iterator is builtin (array, map, set, string). This reduces GC pressure significantly and avoids extracting the `value` and `done` properties. This change makes this micro benchmark 48% faster on my computer: ```js const arr = new Array(10_000_000); let counter = 0; for (let _ of arr) { counter++; } ```
2025-04-30 16:31:26 +03:00
// c. If Type(nextResult) is not Object, throw a TypeError exception.
generator.emit<Bytecode::Op::ThrowIfNotObject>(next_result);
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
LibJS: Skip iterator result object allocation in for..of and for..in Introduce special instruction for `for..of` and `for..in` loop that skips `{ value, done }` result object allocation if iterator is builtin (array, map, set, string). This reduces GC pressure significantly and avoids extracting the `value` and `done` properties. This change makes this micro benchmark 48% faster on my computer: ```js const arr = new Array(10_000_000); let counter = 0; for (let _ of arr) { counter++; } ```
2025-04-30 16:31:26 +03:00
// d. Let done be ? IteratorComplete(nextResult).
generator.emit_iterator_complete(done, next_result);
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
LibJS: Skip iterator result object allocation in for..of and for..in Introduce special instruction for `for..of` and `for..in` loop that skips `{ value, done }` result object allocation if iterator is builtin (array, map, set, string). This reduces GC pressure significantly and avoids extracting the `value` and `done` properties. This change makes this micro benchmark 48% faster on my computer: ```js const arr = new Array(10_000_000); let counter = 0; for (let _ of arr) { counter++; } ```
2025-04-30 16:31:26 +03:00
// e. If done is true, return V.
auto& loop_continue = generator.make_block();
generator.emit_jump_if(
done,
Bytecode::Label { loop_end },
Bytecode::Label { loop_continue });
generator.switch_to_basic_block(loop_continue);
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
LibJS: Skip iterator result object allocation in for..of and for..in Introduce special instruction for `for..of` and `for..in` loop that skips `{ value, done }` result object allocation if iterator is builtin (array, map, set, string). This reduces GC pressure significantly and avoids extracting the `value` and `done` properties. This change makes this micro benchmark 48% faster on my computer: ```js const arr = new Array(10_000_000); let counter = 0; for (let _ of arr) { counter++; } ```
2025-04-30 16:31:26 +03:00
// f. Let nextValue be ? IteratorValue(nextResult).
generator.emit_iterator_value(next_value, next_result);
}
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
LibJS: Call IteratorClose on abrupt completion in for-of loops When a for-of or for-await-of loop exits via break, return, throw, or continue-to-outer-loop, we now correctly call IteratorClose (or AsyncIteratorClose) to give the iterator a chance to clean up resources. This uses a synthetic FinallyContext that wraps the LHS assignment and loop body, reusing the existing try/finally completion record machinery. The ReturnToFinally boundary is placed between Break and Continue so that continue-to-same-loop bypasses the close (zero overhead on normal iteration) while all other abrupt exits route through the iterator close dispatch chain. for-in (enumerate) does not require iterator close per spec.
2026-02-11 23:49:53 +01:00
// Set up the exception handler now, after the iterator-next section.
// This ensures only LHS assignment and body exceptions trigger close.
// We must also switch to a fresh block so that subsequent code gets the
// new handler (make_block sets the handler at creation time).
if (needs_iterator_close) {
iterator_close_unwind_context.emplace(generator, Bytecode::Label { *exception_preamble_block });
auto& loop_body = generator.make_block();
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { loop_body });
generator.switch_to_basic_block(loop_body);
}
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
// g. If lhsKind is either assignment or varBinding, then
if (head_result.lhs_kind != LHSKind::LexicalBinding) {
// i. If destructuring is false, then
if (!destructuring) {
// 1. Let lhsRef be the result of evaluating lhs. (It may be evaluated repeatedly.)
// NOTE: We're skipping all the completion stuff that the spec does, as the unwinding mechanism will take case of doing that.
if (head_result.lhs_kind == LHSKind::VarBinding) {
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
auto& declaration = static_cast<VariableDeclaration const&>(*lhs.get<NonnullRefPtr<ASTNode const>>());
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
VERIFY(declaration.declarations().size() == 1);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
assign_value_to_variable_declarator(generator, declaration.declarations().first(), declaration, next_value);
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
} else {
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
if (auto ptr = lhs.get_pointer<NonnullRefPtr<ASTNode const>>()) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
generator.emit_store_to_reference(**ptr, next_value);
LibJS: Don't assume that for-in/of target is a variable on LHS::Assign e.g. `for ([foo.bar] in ...)` is actually a binding pattern.
2022-03-31 03:09:36 +04:30
} else {
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
auto& binding_pattern = lhs.get<NonnullRefPtr<BindingPattern const>>();
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
binding_pattern->generate_bytecode(generator, Bytecode::Op::BindingInitializationMode::Set, next_value);
LibJS: Don't assume that for-in/of target is a variable on LHS::Assign e.g. `for ([foo.bar] in ...)` is actually a binding pattern.
2022-03-31 03:09:36 +04:30
}
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
}
}
}
// h. Else,
else {
// i. Assert: lhsKind is lexicalBinding.
// ii. Assert: lhs is a ForDeclaration.
// iii. Let iterationEnv be NewDeclarativeEnvironment(oldEnv).
// iv. Perform ForDeclarationBindingInstantiation of lhs with argument iterationEnv.
// v. Set the running execution context's LexicalEnvironment to iterationEnv.
// 14.7.5.4 Runtime Semantics: ForDeclarationBindingInstantiation, https://tc39.es/ecma262/#sec-runtime-semantics-fordeclarationbindinginstantiation
// 1. Assert: environment is a declarative Environment Record.
// NOTE: We just made it.
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
auto& variable_declaration = static_cast<VariableDeclaration const&>(*lhs.get<NonnullRefPtr<ASTNode const>>());
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
// 2. For each element name of the BoundNames of ForBinding, do
LibJS: Don't discard ThrowCompletionOr<void> from declaration iteration
2023-02-27 22:13:37 +00:00
// NOTE: Nothing in the callback throws an exception.
LibJS: Elide empty lexical environment in for..in/of blocks When all the variables in a for..in/of block's lexical scope have been turned into locals, we don't need to create and immediately abandon an empty environment for them. This avoid environment allocation in cases like this: function foo(a) { for (const x of a) { } }
2023-12-06 15:07:42 +01:00
auto has_non_local_variables = false;
LibJS/Bytecode: Skip CreateVariable for locals in "for" loop head CreateVariable is not needed for locals because they are not stored in environment and created binding will not be used. Also if all variables in loop initialization sections are local then CreateLexicalEnvironment and LeaveLexicalEnvironment can also be ommitted.
2023-07-13 21:30:36 +02:00
MUST(variable_declaration.for_each_bound_identifier([&](auto const& identifier) {
LibJS: Elide empty lexical environment in for..in/of blocks When all the variables in a for..in/of block's lexical scope have been turned into locals, we don't need to create and immediately abandon an empty environment for them. This avoid environment allocation in cases like this: function foo(a) { for (const x of a) { } }
2023-12-06 15:07:42 +01:00
if (!identifier.is_local())
has_non_local_variables = true;
LibJS: Don't discard ThrowCompletionOr<void> from declaration iteration
2023-02-27 22:13:37 +00:00
}));
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
LibJS: Elide empty lexical environment in for..in/of blocks When all the variables in a for..in/of block's lexical scope have been turned into locals, we don't need to create and immediately abandon an empty environment for them. This avoid environment allocation in cases like this: function foo(a) { for (const x of a) { } }
2023-12-06 15:07:42 +01:00
if (has_non_local_variables) {
generator.begin_variable_scope();
has_lexical_binding = true;
MUST(variable_declaration.for_each_bound_identifier([&](auto const& identifier) {
if (identifier.is_local())
return;
auto interned_identifier = generator.intern_identifier(identifier.string());
// a. If IsConstantDeclaration of LetOrConst is true, then
if (variable_declaration.is_constant_declaration()) {
// i. Perform ! environment.CreateImmutableBinding(name, true).
generator.emit<Bytecode::Op::CreateVariable>(interned_identifier, Bytecode::Op::EnvironmentMode::Lexical, true, false, true);
}
// b. Else,
else {
// i. Perform ! environment.CreateMutableBinding(name, false).
LibJS: Generate C++ bytecode instruction classes from a definition file This commit adds a new Bytecode.def file that describes all the LibJS bytecode instructions. From this, we are able to generate the full declarations for all C++ bytecode instruction classes, as well as their serialization code. Note that some of the bytecode compiler was updated since instructions no longer have default constructor arguments. The big immediate benefit here is that we lose a couple thousand lines of hand-written C++ code. Going forward, this also allows us to do more tooling for the bytecode VM, now that we have an authoritative description of its instructions. Key things to know about: - Instructions can inherit from one another. At the moment, everything simply inherits from the base "Instruction". - @terminator means the instruction terminates a basic block. - @nothrow means the instruction cannot throw. This affects how the interpreter interacts with it. - Variable-length instructions are automatically supported. Just put an array of something as the last field of the instruction. - The m_length field is magical. If present, it will be populated with the full length of the instruction. This is used for variable-length instructions.
2025-11-20 22:14:50 +01:00
generator.emit<Bytecode::Op::CreateVariable>(interned_identifier, Bytecode::Op::EnvironmentMode::Lexical, false, false, false);
LibJS: Elide empty lexical environment in for..in/of blocks When all the variables in a for..in/of block's lexical scope have been turned into locals, we don't need to create and immediately abandon an empty environment for them. This avoid environment allocation in cases like this: function foo(a) { for (const x of a) { } }
2023-12-06 15:07:42 +01:00
}
}));
// 3. Return unused.
// NOTE: No need to do that as we've inlined this.
}
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
// vi. If destructuring is false, then
if (!destructuring) {
// 1. Assert: lhs binds a single name.
// 2. Let lhsName be the sole element of BoundNames of lhs.
LibJS: Update bytecode generator to use local variables - Update ECMAScriptFunctionObject::function_declaration_instantiation to initialize local variables - Introduce GetLocal, SetLocal, TypeofLocal that will be used to operate on local variables. - Update bytecode generator to emit instructions for local variables
2023-07-05 02:17:10 +02:00
auto lhs_name = variable_declaration.declarations().first()->target().get<NonnullRefPtr<Identifier const>>();
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
// 3. Let lhsRef be ! ResolveBinding(lhsName).
// NOTE: We're skipping all the completion stuff that the spec does, as the unwinding mechanism will take case of doing that.
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
LibJS/Bytecode: Split SetVariable into four separate instructions Instead of SetVariable having 2x2 modes for variable/lexical and initialize/set, those 4 modes are now separate instructions, which makes each instruction much less branchy.
2024-05-14 11:30:30 +02:00
generator.emit_set_variable(*lhs_name, next_value, Bytecode::Op::BindingInitializationMode::Initialize, Bytecode::Op::EnvironmentMode::Lexical);
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
}
}
// i. If destructuring is false, then
if (!destructuring) {
// i. If lhsRef is an abrupt completion, then
// 1. Let status be lhsRef.
// ii. Else if lhsKind is lexicalBinding, then
// 1. Let status be Completion(InitializeReferencedBinding(lhsRef, nextValue)).
// iii. Else,
// 1. Let status be Completion(PutValue(lhsRef, nextValue)).
// NOTE: This is performed above.
}
// j. Else,
else {
LibJS/Bytecode: Implement var/lexical binding destructuring in for/of
2022-12-09 18:47:51 +00:00
// FIXME: i. If lhsKind is assignment, then
// 1. Let status be Completion(DestructuringAssignmentEvaluation of assignmentPattern with argument nextValue).
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
// ii. Else if lhsKind is varBinding, then
// 1. Assert: lhs is a ForBinding.
// 2. Let status be Completion(BindingInitialization of lhs with arguments nextValue and undefined).
// iii. Else,
// 1. Assert: lhsKind is lexicalBinding.
// 2. Assert: lhs is a ForDeclaration.
// 3. Let status be Completion(ForDeclarationBindingInitialization of lhs with arguments nextValue and iterationEnv).
LibJS/Bytecode: Implement var/lexical binding destructuring in for/of
2022-12-09 18:47:51 +00:00
if (head_result.lhs_kind == LHSKind::VarBinding || head_result.lhs_kind == LHSKind::LexicalBinding) {
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
auto& declaration = static_cast<VariableDeclaration const&>(*lhs.get<NonnullRefPtr<ASTNode const>>());
LibJS/Bytecode: Implement var/lexical binding destructuring in for/of
2022-12-09 18:47:51 +00:00
VERIFY(declaration.declarations().size() == 1);
Everywhere: Stop using NonnullRefPtrVector This class had slightly confusing semantics and the added weirdness doesn't seem worth it just so we can say "." instead of "->" when iterating over a vector of NNRPs. This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
2023-03-06 14:17:01 +01:00
auto& binding_pattern = declaration.declarations().first()->target().get<NonnullRefPtr<BindingPattern const>>();
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
binding_pattern->generate_bytecode(
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator,
LibJS/Bytecode: Split SetVariable into four separate instructions Instead of SetVariable having 2x2 modes for variable/lexical and initialize/set, those 4 modes are now separate instructions, which makes each instruction much less branchy.
2024-05-14 11:30:30 +02:00
head_result.lhs_kind == LHSKind::VarBinding ? Bytecode::Op::BindingInitializationMode::Set : Bytecode::Op::BindingInitializationMode::Initialize,
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
next_value);
LibJS/Bytecode: Implement var/lexical binding destructuring in for/of
2022-12-09 18:47:51 +00:00
} else {
LibJS: Convert unreachable codegen error sites to VERIFY Replace CodeGenerationError returns with VERIFY_NOT_REACHED() or VERIFY() at sites that are provably unreachable: - Non-computed member expression fallbacks in emit_load_from_reference, emit_store_to_reference, and emit_delete_reference (member expression properties are always computed, identifier, or private identifier) - Two non-computed member expression fallbacks in AssignmentExpression - Default case in compound assignment switch (all 15 AssignmentOp values are handled) - BindingPattern Empty/Expression name+alias pair (computed property names always require an alias) - Two assignment+destructuring combinations in for-in/of body evaluation (is_destructuring is only set for VariableDeclaration lhs, which always has VarBinding or LexicalBinding kind, never Assignment)
2026-02-11 22:05:55 +01:00
// NB: lhs_kind is Assignment only when is_destructuring is false, so this is unreachable.
VERIFY_NOT_REACHED();
LibJS/Bytecode: Implement var/lexical binding destructuring in for/of
2022-12-09 18:47:51 +00:00
}
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
}
// k. If status is an abrupt completion, then
// i. Set the running execution context's LexicalEnvironment to oldEnv.
// ii. If iteratorKind is async, return ? AsyncIteratorClose(iteratorRecord, status).
// iii. If iterationKind is enumerate, then
// 1. Return ? status.
// iv. Else,
// 1. Assert: iterationKind is iterate.
// 2. Return ? IteratorClose(iteratorRecord, status).
LibJS: Call IteratorClose on abrupt completion in for-of loops When a for-of or for-await-of loop exits via break, return, throw, or continue-to-outer-loop, we now correctly call IteratorClose (or AsyncIteratorClose) to give the iterator a chance to clean up resources. This uses a synthetic FinallyContext that wraps the LHS assignment and loop body, reusing the existing try/finally completion record machinery. The ReturnToFinally boundary is placed between Break and Continue so that continue-to-same-loop bypasses the close (zero overhead on normal iteration) while all other abrupt exits route through the iterator close dispatch chain. for-in (enumerate) does not require iterator close per spec.
2026-02-11 23:49:53 +01:00
// NB: Abrupt completions from LHS assignment and the loop body are handled
// by the synthetic FinallyContext set up above (for iterate/async-iterate).
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
// l. Let result be the result of evaluating stmt.
LibJS: Don't emit dead code after Throw for invalid LHS expressions When the left-hand side of an assignment, update, or for-in loop is invalid (e.g. `foo() = "bar"`), the bytecode generator emits a Throw instruction. Previously, it would also create a dead basic block after the Throw, resulting in unreachable instructions in the output. Fix this by returning early from the relevant codegen paths after emitting the Throw, and by guarding for-in/for-of body generation with an is_current_block_terminated() check.
2026-03-01 13:17:26 +01:00
if (!generator.is_current_block_terminated()) {
LibJS: Fix UpdateEmpty completion value semantics for loops/switch/if When a loop or switch body produces an abrupt completion (break or continue) with an empty value, the ES spec requires UpdateEmpty to replace the empty value with the last non-empty completion value V. The bytecode compiler was failing to do this because it only updated the completion register after body codegen, guarded by !is_current_block_terminated(). When break/continue terminated the block, the update was skipped. Fix this with three changes: 1. Introduce a CompletionRegisterScope that tells ScopeNode::generate_bytecode to eagerly emit Mov instructions into the completion register after each value-producing statement. This ensures the register is up to date before any break or continue fires. 2. Give IfStatement its own CompletionRegisterScope (initialized to undefined) during branch evaluation. This models the spec's UpdateEmpty(stmtCompletion, undefined) for if-statements: when break/continue fires inside an if-branch, the scoped jump propagation sees that the if's completion register differs from the loop's and emits a Mov, correctly replacing the eagerly written value with undefined. Without this, code like { 3; if (true) { break; } else { } } would incorrectly carry the value 3 instead of undefined through the break. 3. Capture loop body results and emit a fallback Mov for non-ScopeNode bodies (e.g. bare expression statements like do x=1; while(false)) that don't participate in the eager CompletionRegisterScope update mechanism. For labelled break/continue that cross loop boundaries, the jump codegen now propagates the inner completion register to the target scope's completion register before emitting the jump. Also fix ForStatement to use a proper completion register (previously it returned the body result directly, which was wrong for empty bodies and break-with-no-value cases).
2026-02-10 23:25:24 +01:00
Optional<Bytecode::Generator::CompletionRegisterScope> completion_scope;
if (completion.has_value())
completion_scope.emplace(generator, *completion);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto result = body.generate_bytecode(generator);
LibJS: Fix UpdateEmpty completion value semantics for loops/switch/if When a loop or switch body produces an abrupt completion (break or continue) with an empty value, the ES spec requires UpdateEmpty to replace the empty value with the last non-empty completion value V. The bytecode compiler was failing to do this because it only updated the completion register after body codegen, guarded by !is_current_block_terminated(). When break/continue terminated the block, the update was skipped. Fix this with three changes: 1. Introduce a CompletionRegisterScope that tells ScopeNode::generate_bytecode to eagerly emit Mov instructions into the completion register after each value-producing statement. This ensures the register is up to date before any break or continue fires. 2. Give IfStatement its own CompletionRegisterScope (initialized to undefined) during branch evaluation. This models the spec's UpdateEmpty(stmtCompletion, undefined) for if-statements: when break/continue fires inside an if-branch, the scoped jump propagation sees that the if's completion register differs from the loop's and emits a Mov, correctly replacing the eagerly written value with undefined. Without this, code like { 3; if (true) { break; } else { } } would incorrectly carry the value 3 instead of undefined through the break. 3. Capture loop body results and emit a fallback Mov for non-ScopeNode bodies (e.g. bare expression statements like do x=1; while(false)) that don't participate in the eager CompletionRegisterScope update mechanism. For labelled break/continue that cross loop boundaries, the jump codegen now propagates the inner completion register to the target scope's completion register before emitting the jump. Also fix ForStatement to use a proper completion register (previously it returned the body result directly, which was wrong for empty bodies and break-with-no-value cases).
2026-02-10 23:25:24 +01:00
if (!generator.is_current_block_terminated() && completion.has_value() && result.has_value())
generator.emit_mov(*completion, *result);
}
LibJS/Bytecode: Leave `for in` and `for of` with right completion value 14 new passes on test262. :^)
2023-07-05 14:07:20 +02:00
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
// m. Set the running execution context's LexicalEnvironment to oldEnv.
if (has_lexical_binding)
generator.end_variable_scope();
generator.end_continuable_scope();
LibJS: Call IteratorClose on abrupt completion in for-of loops When a for-of or for-await-of loop exits via break, return, throw, or continue-to-outer-loop, we now correctly call IteratorClose (or AsyncIteratorClose) to give the iterator a chance to clean up resources. This uses a synthetic FinallyContext that wraps the LHS assignment and loop body, reusing the existing try/finally completion record machinery. The ReturnToFinally boundary is placed between Break and Continue so that continue-to-same-loop bypasses the close (zero overhead on normal iteration) while all other abrupt exits route through the iterator close dispatch chain. for-in (enumerate) does not require iterator close per spec.
2026-02-11 23:49:53 +01:00
if (needs_iterator_close) {
generator.end_boundary(Bytecode::Generator::BlockBoundaryType::ReturnToFinally);
generator.set_current_finally_context(iterator_close_finally_context->parent);
iterator_close_unwind_context.clear();
}
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
generator.end_breakable_scope();
LibJS: Generate update Jump in for/in/of only if block is not terminated The body of for/in/of can contain an unconditional block terminator (e.g. return, throw), so we have to check for that before generating the Jump to the loop update block.
2022-03-27 18:46:25 +01:00
// The body can contain an unconditional block terminator (e.g. return, throw), so we have to check for that before generating the Jump.
LibJS: Fix UpdateEmpty completion value semantics for loops/switch/if When a loop or switch body produces an abrupt completion (break or continue) with an empty value, the ES spec requires UpdateEmpty to replace the empty value with the last non-empty completion value V. The bytecode compiler was failing to do this because it only updated the completion register after body codegen, guarded by !is_current_block_terminated(). When break/continue terminated the block, the update was skipped. Fix this with three changes: 1. Introduce a CompletionRegisterScope that tells ScopeNode::generate_bytecode to eagerly emit Mov instructions into the completion register after each value-producing statement. This ensures the register is up to date before any break or continue fires. 2. Give IfStatement its own CompletionRegisterScope (initialized to undefined) during branch evaluation. This models the spec's UpdateEmpty(stmtCompletion, undefined) for if-statements: when break/continue fires inside an if-branch, the scoped jump propagation sees that the if's completion register differs from the loop's and emits a Mov, correctly replacing the eagerly written value with undefined. Without this, code like { 3; if (true) { break; } else { } } would incorrectly carry the value 3 instead of undefined through the break. 3. Capture loop body results and emit a fallback Mov for non-ScopeNode bodies (e.g. bare expression statements like do x=1; while(false)) that don't participate in the eager CompletionRegisterScope update mechanism. For labelled break/continue that cross loop boundaries, the jump codegen now propagates the inner completion register to the target scope's completion register before emitting the jump. Also fix ForStatement to use a proper completion register (previously it returned the body result directly, which was wrong for empty bodies and break-with-no-value cases).
2026-02-10 23:25:24 +01:00
if (!generator.is_current_block_terminated())
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { loop_update });
LibJS: Generate update Jump in for/in/of only if block is not terminated The body of for/in/of can contain an unconditional block terminator (e.g. return, throw), so we have to check for that before generating the Jump to the loop update block.
2022-03-27 18:46:25 +01:00
LibJS: Call IteratorClose on abrupt completion in for-of loops When a for-of or for-await-of loop exits via break, return, throw, or continue-to-outer-loop, we now correctly call IteratorClose (or AsyncIteratorClose) to give the iterator a chance to clean up resources. This uses a synthetic FinallyContext that wraps the LHS assignment and loop body, reusing the existing try/finally completion record machinery. The ReturnToFinally boundary is placed between Break and Continue so that continue-to-same-loop bypasses the close (zero overhead on normal iteration) while all other abrupt exits route through the iterator close dispatch chain. for-in (enumerate) does not require iterator close per spec.
2026-02-11 23:49:53 +01:00
// Generate iterator close blocks for for-of/for-await-of.
if (needs_iterator_close) {
auto undefined_value = generator.add_constant(js_undefined());
// Exception preamble: catches thrown exceptions and routes to iterator close.
generator.switch_to_basic_block(*exception_preamble_block);
generator.emit<Bytecode::Op::Catch>(*close_completion_value);
generator.emit<Bytecode::Op::SetLexicalEnvironment>(*lexical_environment_at_entry);
generator.emit_mov(*close_completion_type, generator.add_constant(Value(Bytecode::Generator::FinallyContext::THROW)));
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { *iterator_close_body_block });
// Iterator close body: dispatch chain based on completion type.
generator.switch_to_basic_block(*iterator_close_body_block);
// THROW path: IteratorClose with Throw completion (original throw always wins).
auto& throw_close_block = generator.make_block();
auto& non_throw_close_block = generator.make_block();
generator.emit<Bytecode::Op::JumpStrictlyEquals>(
*close_completion_type, generator.add_constant(Value(Bytecode::Generator::FinallyContext::THROW)),
Bytecode::Label { throw_close_block }, Bytecode::Label { non_throw_close_block });
// Non-throw abrupt path (break/return/continue-to-outer): close with Normal completion.
generator.switch_to_basic_block(non_throw_close_block);
LibJS: Inline AsyncIteratorClose with proper Await in for-await-of The AsyncIteratorClose bytecode op calls async_iterator_close() which uses synchronous await() internally. This spins the event loop while execution contexts are on the stack, violating the microtask checkpoint assertion in LibWeb. Replace AsyncIteratorClose op emissions in for-await-of close handlers with inline bytecode that uses the proper Await op, allowing the async function to yield and resume naturally through the event loop. For the non-throw path (break/return/continue-to-outer): emit GetMethod, Call, Await, and ThrowIfNotObject inline. For the throw path: wrap the close steps in an exception handler so that any error from GetMethod/Call/Await is discarded and the original exception is rethrown, per spec step 5.
2026-02-12 01:29:28 +01:00
if (iterator_kind == IteratorHint::Async) {
// For async iterators, we inline the AsyncIteratorClose steps
// using a proper Await op instead of the synchronous await()
// that the AsyncIteratorClose C++ op uses. The synchronous await
// spins the event loop inside bytecode execution, which violates
// the microtask checkpoint assertion.
auto& after_close = generator.make_block();
// Spec: 7.4.13 AsyncIteratorClose ( iteratorRecord, completion )
// 3. Let innerResult be Completion(GetMethod(iterator, "return")).
auto return_method = generator.allocate_register();
generator.emit<Bytecode::Op::GetMethod>(return_method, *head_result.iterator_object, generator.intern_property_key("return"_utf16_fly_string));
// 4a/b. If return is undefined, skip close.
auto& call_return_block = generator.make_block();
generator.emit<Bytecode::Op::JumpUndefined>(return_method, Bytecode::Label { after_close }, Bytecode::Label { call_return_block });
generator.switch_to_basic_block(call_return_block);
// 4c. Set innerResult to Completion(Call(return, iterator)).
auto inner_result = generator.allocate_register();
generator.emit_with_extra_operand_slots<Bytecode::Op::Call>(0, inner_result, return_method, *head_result.iterator_object, OptionalNone {}, ReadonlySpan<ScopedOperand> {});
// 4d. Set innerResult to Completion(Await(innerResult.[[Value]])).
auto received_completion = generator.allocate_register();
auto received_completion_type = generator.allocate_register();
auto received_completion_value = generator.allocate_register();
auto awaited = generate_await(generator, inner_result, received_completion, received_completion_type, received_completion_value);
// 7. If Type(innerResult.[[Value]]) is not Object, throw a TypeError exception.
generator.emit<Bytecode::Op::ThrowIfNotObject>(awaited);
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { after_close });
generator.switch_to_basic_block(after_close);
} else {
LibJS: Call IteratorClose on abrupt completion in for-of loops When a for-of or for-await-of loop exits via break, return, throw, or continue-to-outer-loop, we now correctly call IteratorClose (or AsyncIteratorClose) to give the iterator a chance to clean up resources. This uses a synthetic FinallyContext that wraps the LHS assignment and loop body, reusing the existing try/finally completion record machinery. The ReturnToFinally boundary is placed between Break and Continue so that continue-to-same-loop bypasses the close (zero overhead on normal iteration) while all other abrupt exits route through the iterator close dispatch chain. for-in (enumerate) does not require iterator close per spec.
2026-02-11 23:49:53 +01:00
generator.emit<Bytecode::Op::IteratorClose>(*head_result.iterator_object, *head_result.iterator_next_method, *head_result.iterator_done_property, Completion::Type::Normal, undefined_value);
LibJS: Inline AsyncIteratorClose with proper Await in for-await-of The AsyncIteratorClose bytecode op calls async_iterator_close() which uses synchronous await() internally. This spins the event loop while execution contexts are on the stack, violating the microtask checkpoint assertion in LibWeb. Replace AsyncIteratorClose op emissions in for-await-of close handlers with inline bytecode that uses the proper Await op, allowing the async function to yield and resume naturally through the event loop. For the non-throw path (break/return/continue-to-outer): emit GetMethod, Call, Await, and ThrowIfNotObject inline. For the throw path: wrap the close steps in an exception handler so that any error from GetMethod/Call/Await is discarded and the original exception is rethrown, per spec step 5.
2026-02-12 01:29:28 +01:00
}
LibJS: Call IteratorClose on abrupt completion in for-of loops When a for-of or for-await-of loop exits via break, return, throw, or continue-to-outer-loop, we now correctly call IteratorClose (or AsyncIteratorClose) to give the iterator a chance to clean up resources. This uses a synthetic FinallyContext that wraps the LHS assignment and loop body, reusing the existing try/finally completion record machinery. The ReturnToFinally boundary is placed between Break and Continue so that continue-to-same-loop bypasses the close (zero overhead on normal iteration) while all other abrupt exits route through the iterator close dispatch chain. for-in (enumerate) does not require iterator close per spec.
2026-02-11 23:49:53 +01:00
// Dispatch registered jumps (break/continue targets, indices 3+).
for (auto const& jump : iterator_close_finally_context->registered_jumps) {
auto& after_jump_check = generator.make_block();
generator.emit<Bytecode::Op::JumpStrictlyEquals>(
*close_completion_type, generator.add_constant(Value(jump.index)),
jump.target, Bytecode::Label { after_jump_check });
generator.switch_to_basic_block(after_jump_check);
}
// RETURN path.
auto& return_block = generator.make_block();
auto& unreachable_block = generator.make_block();
generator.emit<Bytecode::Op::JumpStrictlyEquals>(
*close_completion_type, generator.add_constant(Value(Bytecode::Generator::FinallyContext::RETURN)),
Bytecode::Label { return_block }, Bytecode::Label { unreachable_block });
generator.switch_to_basic_block(return_block);
if (iterator_close_finally_context->parent) {
// Nested finally: copy completion record to outer and jump to outer finally body.
auto& outer = *iterator_close_finally_context->parent;
generator.emit_mov(outer.completion_type, *close_completion_type);
generator.emit_mov(outer.completion_value, *close_completion_value);
generator.emit<Bytecode::Op::Jump>(outer.finally_body);
} else {
if (generator.is_in_generator_function())
generator.emit<Bytecode::Op::Yield>(OptionalNone {}, *close_completion_value);
else
generator.emit<Bytecode::Op::Return>(*close_completion_value);
}
// Default: unreachable (all completion types have been dispatched).
generator.switch_to_basic_block(unreachable_block);
generator.emit<Bytecode::Op::Throw>(*close_completion_value);
// Throw close block: IteratorClose with Throw completion, then rethrow.
LibJS: Inline AsyncIteratorClose with proper Await in for-await-of The AsyncIteratorClose bytecode op calls async_iterator_close() which uses synchronous await() internally. This spins the event loop while execution contexts are on the stack, violating the microtask checkpoint assertion in LibWeb. Replace AsyncIteratorClose op emissions in for-await-of close handlers with inline bytecode that uses the proper Await op, allowing the async function to yield and resume naturally through the event loop. For the non-throw path (break/return/continue-to-outer): emit GetMethod, Call, Await, and ThrowIfNotObject inline. For the throw path: wrap the close steps in an exception handler so that any error from GetMethod/Call/Await is discarded and the original exception is rethrown, per spec step 5.
2026-02-12 01:29:28 +01:00
// Per spec step 5, the original throw always takes precedence.
LibJS: Call IteratorClose on abrupt completion in for-of loops When a for-of or for-await-of loop exits via break, return, throw, or continue-to-outer-loop, we now correctly call IteratorClose (or AsyncIteratorClose) to give the iterator a chance to clean up resources. This uses a synthetic FinallyContext that wraps the LHS assignment and loop body, reusing the existing try/finally completion record machinery. The ReturnToFinally boundary is placed between Break and Continue so that continue-to-same-loop bypasses the close (zero overhead on normal iteration) while all other abrupt exits route through the iterator close dispatch chain. for-in (enumerate) does not require iterator close per spec.
2026-02-11 23:49:53 +01:00
generator.switch_to_basic_block(throw_close_block);
LibJS: Inline AsyncIteratorClose with proper Await in for-await-of The AsyncIteratorClose bytecode op calls async_iterator_close() which uses synchronous await() internally. This spins the event loop while execution contexts are on the stack, violating the microtask checkpoint assertion in LibWeb. Replace AsyncIteratorClose op emissions in for-await-of close handlers with inline bytecode that uses the proper Await op, allowing the async function to yield and resume naturally through the event loop. For the non-throw path (break/return/continue-to-outer): emit GetMethod, Call, Await, and ThrowIfNotObject inline. For the throw path: wrap the close steps in an exception handler so that any error from GetMethod/Call/Await is discarded and the original exception is rethrown, per spec step 5.
2026-02-12 01:29:28 +01:00
if (iterator_kind == IteratorHint::Async) {
// Inline AsyncIteratorClose with exception handler: any error from
// the close steps is discarded and the original exception is rethrown.
auto& rethrow_block = generator.make_block();
auto& close_catch_block = generator.make_block();
{
Bytecode::Generator::UnwindContext close_unwind(generator, Bytecode::Label { close_catch_block });
// Jump to a block created inside the UnwindContext so that
// GetMethod/Call/Await all have the exception handler set.
// throw_close_block was created before the UnwindContext and
// doesn't have the handler.
auto& close_try_block = generator.make_block();
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { close_try_block });
generator.switch_to_basic_block(close_try_block);
auto return_method = generator.allocate_register();
generator.emit<Bytecode::Op::GetMethod>(return_method, *head_result.iterator_object, generator.intern_property_key("return"_utf16_fly_string));
auto& call_return_block = generator.make_block();
generator.emit<Bytecode::Op::JumpUndefined>(return_method, Bytecode::Label { rethrow_block }, Bytecode::Label { call_return_block });
generator.switch_to_basic_block(call_return_block);
auto inner_result = generator.allocate_register();
generator.emit_with_extra_operand_slots<Bytecode::Op::Call>(0, inner_result, return_method, *head_result.iterator_object, OptionalNone {}, ReadonlySpan<ScopedOperand> {});
auto received_completion = generator.allocate_register();
auto received_completion_type = generator.allocate_register();
auto received_completion_value = generator.allocate_register();
generate_await(generator, inner_result, received_completion, received_completion_type, received_completion_value);
// Even if close succeeded, rethrow original (spec step 5).
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { rethrow_block });
}
// Exception handler: discard close error, rethrow original.
generator.switch_to_basic_block(close_catch_block);
auto discarded = generator.allocate_register();
generator.emit<Bytecode::Op::Catch>(discarded);
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { rethrow_block });
generator.switch_to_basic_block(rethrow_block);
LibJS: Call IteratorClose on abrupt completion in for-of loops When a for-of or for-await-of loop exits via break, return, throw, or continue-to-outer-loop, we now correctly call IteratorClose (or AsyncIteratorClose) to give the iterator a chance to clean up resources. This uses a synthetic FinallyContext that wraps the LHS assignment and loop body, reusing the existing try/finally completion record machinery. The ReturnToFinally boundary is placed between Break and Continue so that continue-to-same-loop bypasses the close (zero overhead on normal iteration) while all other abrupt exits route through the iterator close dispatch chain. for-in (enumerate) does not require iterator close per spec.
2026-02-11 23:49:53 +01:00
generator.emit<Bytecode::Op::Throw>(*close_completion_value);
LibJS: Inline AsyncIteratorClose with proper Await in for-await-of The AsyncIteratorClose bytecode op calls async_iterator_close() which uses synchronous await() internally. This spins the event loop while execution contexts are on the stack, violating the microtask checkpoint assertion in LibWeb. Replace AsyncIteratorClose op emissions in for-await-of close handlers with inline bytecode that uses the proper Await op, allowing the async function to yield and resume naturally through the event loop. For the non-throw path (break/return/continue-to-outer): emit GetMethod, Call, Await, and ThrowIfNotObject inline. For the throw path: wrap the close steps in an exception handler so that any error from GetMethod/Call/Await is discarded and the original exception is rethrown, per spec step 5.
2026-02-12 01:29:28 +01:00
} else {
generator.emit<Bytecode::Op::IteratorClose>(*head_result.iterator_object, *head_result.iterator_next_method, *head_result.iterator_done_property, Completion::Type::Throw, *close_completion_value);
// iterator_close with Throw completion always re-throws, but if it
// somehow returns normally, rethrow the original exception.
if (!generator.is_current_block_terminated())
generator.emit<Bytecode::Op::Throw>(*close_completion_value);
}
LibJS: Call IteratorClose on abrupt completion in for-of loops When a for-of or for-await-of loop exits via break, return, throw, or continue-to-outer-loop, we now correctly call IteratorClose (or AsyncIteratorClose) to give the iterator a chance to clean up resources. This uses a synthetic FinallyContext that wraps the LHS assignment and loop body, reusing the existing try/finally completion record machinery. The ReturnToFinally boundary is placed between Break and Continue so that continue-to-same-loop bypasses the close (zero overhead on normal iteration) while all other abrupt exits route through the iterator close dispatch chain. for-in (enumerate) does not require iterator close per spec.
2026-02-11 23:49:53 +01:00
}
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
generator.switch_to_basic_block(loop_end);
LibJS/Bytecode: Don't bother propagating completion values in functions The last completion value in a function is not exposed to the language, since functions always either return something, or undefined. Given this, we can avoid emitting code that propagates the completion value from various statements, as long as we know we're generating code for a context where the completion value is not accessible. In practical terms, this means that function code gets to do less completion shuffling, while global and eval code has to keep doing it.
2024-05-14 10:57:06 +02:00
return completion;
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> ForInStatement::generate_bytecode(Bytecode::Generator& generator, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
return generate_labelled_evaluation(generator, {});
}
// 14.7.5.5 Runtime Semantics: ForInOfLoopEvaluation, https://tc39.es/ecma262/#sec-runtime-semantics-forinofloopevaluation
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> ForInStatement::generate_labelled_evaluation(Bytecode::Generator& generator, Vector<FlyString> const& label_set, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
{
auto& loop_end = generator.make_block();
auto& loop_update = generator.make_block();
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
generator.begin_breakable_scope(Bytecode::Label { loop_end }, label_set);
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto head_result = for_in_of_head_evaluation(generator, IterationKind::Enumerate, m_lhs, m_rhs);
LibJS: Call IteratorClose on abrupt completion in for-of loops When a for-of or for-await-of loop exits via break, return, throw, or continue-to-outer-loop, we now correctly call IteratorClose (or AsyncIteratorClose) to give the iterator a chance to clean up resources. This uses a synthetic FinallyContext that wraps the LHS assignment and loop body, reusing the existing try/finally completion record machinery. The ReturnToFinally boundary is placed between Break and Continue so that continue-to-same-loop bypasses the close (zero overhead on normal iteration) while all other abrupt exits route through the iterator close dispatch chain. for-in (enumerate) does not require iterator close per spec.
2026-02-11 23:49:53 +01:00
return for_in_of_body_evaluation(generator, m_lhs, body(), head_result, IterationKind::Enumerate, label_set, loop_end, loop_update);
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> ForOfStatement::generate_bytecode(Bytecode::Generator& generator, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
return generate_labelled_evaluation(generator, {});
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> ForOfStatement::generate_labelled_evaluation(Bytecode::Generator& generator, Vector<FlyString> const& label_set, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
{
auto& loop_end = generator.make_block();
auto& loop_update = generator.make_block();
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
generator.begin_breakable_scope(Bytecode::Label { loop_end }, label_set);
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto head_result = for_in_of_head_evaluation(generator, IterationKind::Iterate, m_lhs, m_rhs);
LibJS: Call IteratorClose on abrupt completion in for-of loops When a for-of or for-await-of loop exits via break, return, throw, or continue-to-outer-loop, we now correctly call IteratorClose (or AsyncIteratorClose) to give the iterator a chance to clean up resources. This uses a synthetic FinallyContext that wraps the LHS assignment and loop body, reusing the existing try/finally completion record machinery. The ReturnToFinally boundary is placed between Break and Continue so that continue-to-same-loop bypasses the close (zero overhead on normal iteration) while all other abrupt exits route through the iterator close dispatch chain. for-in (enumerate) does not require iterator close per spec.
2026-02-11 23:49:53 +01:00
return for_in_of_body_evaluation(generator, m_lhs, body(), head_result, IterationKind::Iterate, label_set, loop_end, loop_update);
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> ForAwaitOfStatement::generate_bytecode(Bytecode::Generator& generator, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS/Bytecode: Implement for await of Summary: Diff Tests: +391 ✅ +15 ❌ +2 💥️ -408 📝
2023-06-27 19:24:34 +01:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS/Bytecode: Implement for await of Summary: Diff Tests: +391 ✅ +15 ❌ +2 💥️ -408 📝
2023-06-27 19:24:34 +01:00
return generate_labelled_evaluation(generator, {});
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> ForAwaitOfStatement::generate_labelled_evaluation(Bytecode::Generator& generator, Vector<FlyString> const& label_set, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS/Bytecode: Implement for await of Summary: Diff Tests: +391 ✅ +15 ❌ +2 💥️ -408 📝
2023-06-27 19:24:34 +01:00
{
auto& loop_end = generator.make_block();
auto& loop_update = generator.make_block();
generator.begin_breakable_scope(Bytecode::Label { loop_end }, label_set);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto head_result = for_in_of_head_evaluation(generator, IterationKind::AsyncIterate, m_lhs, m_rhs);
LibJS: Call IteratorClose on abrupt completion in for-of loops When a for-of or for-await-of loop exits via break, return, throw, or continue-to-outer-loop, we now correctly call IteratorClose (or AsyncIteratorClose) to give the iterator a chance to clean up resources. This uses a synthetic FinallyContext that wraps the LHS assignment and loop body, reusing the existing try/finally completion record machinery. The ReturnToFinally boundary is placed between Break and Continue so that continue-to-same-loop bypasses the close (zero overhead on normal iteration) while all other abrupt exits route through the iterator close dispatch chain. for-in (enumerate) does not require iterator close per spec.
2026-02-11 23:49:53 +01:00
return for_in_of_body_evaluation(generator, m_lhs, m_body, head_result, IterationKind::AsyncIterate, label_set, loop_end, loop_update, IteratorHint::Async);
LibJS/Bytecode: Implement for await of Summary: Diff Tests: +391 ✅ +15 ❌ +2 💥️ -408 📝
2023-06-27 19:24:34 +01:00
}
LibJS/Bytecode: Add support for new.target
2022-03-19 19:40:21 +00:00
// 13.3.12.1 Runtime Semantics: Evaluation, https://tc39.es/ecma262/#sec-meta-properties-runtime-semantics-evaluation
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> MetaProperty::generate_bytecode(Bytecode::Generator& generator, Optional<ScopedOperand> preferred_dst) const
LibJS/Bytecode: Add support for new.target
2022-03-19 19:40:21 +00:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS/Bytecode: Add support for new.target
2022-03-19 19:40:21 +00:00
// NewTarget : new . target
if (m_type == MetaProperty::Type::NewTarget) {
// 1. Return GetNewTarget().
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
auto dst = choose_dst(generator, preferred_dst);
generator.emit<Bytecode::Op::GetNewTarget>(dst);
return dst;
LibJS/Bytecode: Add support for new.target
2022-03-19 19:40:21 +00:00
}
// ImportMeta : import . meta
if (m_type == MetaProperty::Type::ImportMeta) {
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
auto dst = choose_dst(generator, preferred_dst);
generator.emit<Bytecode::Op::GetImportMeta>(dst);
return dst;
LibJS/Bytecode: Add support for new.target
2022-03-19 19:40:21 +00:00
}
VERIFY_NOT_REACHED();
}
LibJS/Bytecode: Support class field initializers Fixes 513 test262 tests. :^)
2023-06-17 10:11:23 +02:00
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> ClassFieldInitializerStatement::generate_bytecode(Bytecode::Generator& generator, Optional<ScopedOperand> preferred_dst) const
LibJS/Bytecode: Support class field initializers Fixes 513 test262 tests. :^)
2023-06-17 10:11:23 +02:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto value = generator.emit_named_evaluation_if_anonymous_function(*m_expression, generator.intern_identifier(m_class_field_identifier_name), preferred_dst);
LibJS/Bytecode: Support class field initializers Fixes 513 test262 tests. :^)
2023-06-17 10:11:23 +02:00
generator.perform_needed_unwinds<Bytecode::Op::Return>();
LibJS: Always emit value in emit_named_evaluation_if_anonymous_function There does not appear to be any case that we need to return an OptionalNone{}.
2025-05-16 12:31:42 +12:00
generator.emit<Bytecode::Op::Return>(value.operand());
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return value;
LibJS/Bytecode: Support class field initializers Fixes 513 test262 tests. :^)
2023-06-17 10:11:23 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
static void generate_optional_chain(Bytecode::Generator& generator, OptionalChain const& optional_chain, ScopedOperand current_value, ScopedOperand current_base, [[maybe_unused]] Optional<ScopedOperand> preferred_dst)
LibJS/Bytecode: Implement optional chaining
2023-06-17 14:50:23 +01:00
{
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
Optional<ScopedOperand> new_current_value;
LibJS/Bytecode: Implement optional chaining
2023-06-17 14:50:23 +01:00
if (is<MemberExpression>(optional_chain.base())) {
auto& member_expression = static_cast<MemberExpression const&>(optional_chain.base());
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto base_and_value = get_base_and_value_from_member_expression(generator, member_expression);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
new_current_value = base_and_value.value;
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(current_base, base_and_value.base);
LibJS/Bytecode: Implement optional chaining
2023-06-17 14:50:23 +01:00
} else if (is<OptionalChain>(optional_chain.base())) {
auto& sub_optional_chain = static_cast<OptionalChain const&>(optional_chain.base());
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
generate_optional_chain(generator, sub_optional_chain, current_value, current_base);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
new_current_value = current_value;
LibJS/Bytecode: Implement optional chaining
2023-06-17 14:50:23 +01:00
} else {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
new_current_value = optional_chain.base().generate_bytecode(generator).value();
LibJS/Bytecode: Implement optional chaining
2023-06-17 14:50:23 +01:00
}
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(current_value, *new_current_value);
LibJS/Bytecode: Implement optional chaining
2023-06-17 14:50:23 +01:00
auto& load_undefined_and_jump_to_end_block = generator.make_block();
auto& end_block = generator.make_block();
for (auto& reference : optional_chain.references()) {
auto is_optional = reference.visit([](auto& ref) { return ref.mode; }) == OptionalChain::Mode::Optional;
if (is_optional) {
auto& not_nullish_block = generator.make_block();
generator.emit<Bytecode::Op::JumpNullish>(
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
current_value,
LibJS/Bytecode: Implement optional chaining
2023-06-17 14:50:23 +01:00
Bytecode::Label { load_undefined_and_jump_to_end_block },
Bytecode::Label { not_nullish_block });
generator.switch_to_basic_block(not_nullish_block);
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
reference.visit(
[&](OptionalChain::Call const& call) -> void {
auto arguments = arguments_to_array_for_call(generator, call.arguments).value();
LibJS: Generate C++ bytecode instruction classes from a definition file This commit adds a new Bytecode.def file that describes all the LibJS bytecode instructions. From this, we are able to generate the full declarations for all C++ bytecode instruction classes, as well as their serialization code. Note that some of the bytecode compiler was updated since instructions no longer have default constructor arguments. The big immediate benefit here is that we lose a couple thousand lines of hand-written C++ code. Going forward, this also allows us to do more tooling for the bytecode VM, now that we have an authoritative description of its instructions. Key things to know about: - Instructions can inherit from one another. At the moment, everything simply inherits from the base "Instruction". - @terminator means the instruction terminates a basic block. - @nothrow means the instruction cannot throw. This affects how the interpreter interacts with it. - Variable-length instructions are automatically supported. Just put an array of something as the last field of the instruction. - The m_length field is magical. If present, it will be populated with the full length of the instruction. This is used for variable-length instructions.
2025-11-20 22:14:50 +01:00
generator.emit<Bytecode::Op::CallWithArgumentArray>(current_value, current_value, current_base, arguments, OptionalNone {});
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(current_base, generator.add_constant(js_undefined()));
LibJS/Bytecode: Implement optional chaining
2023-06-17 14:50:23 +01:00
},
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
[&](OptionalChain::ComputedReference const& ref) -> void {
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(current_base, current_value);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto property = ref.expression->generate_bytecode(generator).value();
LibJS: Emit GetById instead of GetByValue when key is string literal Basically convert o["foo"] into o.foo when emitting bytecode. These are effectively the same thing, and the latter format opts into using an inline cache for the property lookups.
2025-04-03 14:18:24 +02:00
generator.emit_get_by_value(current_value, current_value, property);
LibJS/Bytecode: Implement optional chaining
2023-06-17 14:50:23 +01:00
},
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
[&](OptionalChain::MemberReference const& ref) -> void {
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(current_base, current_value);
LibJS: Cache fully-formed PropertyKeys in Executable Instead of creating PropertyKeys on the fly during interpreter execution, we now store fully-formed ones in the Executable. This avoids a whole bunch of busywork in property access instructions and substantially reduces code size bloat.
2025-12-11 07:57:09 -06:00
generator.emit_get_by_id(current_value, current_value, generator.intern_property_key(ref.identifier->string()));
LibJS/Bytecode: Implement optional chaining
2023-06-17 14:50:23 +01:00
},
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
[&](OptionalChain::PrivateMemberReference const& ref) -> void {
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(current_base, current_value);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.emit<Bytecode::Op::GetPrivateById>(current_value, current_value, generator.intern_identifier(ref.private_identifier->string()));
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
});
LibJS/Bytecode: Implement optional chaining
2023-06-17 14:50:23 +01:00
}
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { end_block });
generator.switch_to_basic_block(load_undefined_and_jump_to_end_block);
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(current_value, generator.add_constant(js_undefined()));
LibJS/Bytecode: Implement optional chaining
2023-06-17 14:50:23 +01:00
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { end_block });
generator.switch_to_basic_block(end_block);
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> OptionalChain::generate_bytecode(Bytecode::Generator& generator, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS/Bytecode: Implement optional chaining
2023-06-17 14:50:23 +01:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
auto current_base = generator.allocate_register();
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
auto current_value = choose_dst(generator, preferred_dst);
LibJS: Optimize away Mov instructions when the source is the destination
2025-03-28 00:56:57 +01:00
generator.emit_mov(current_base, generator.add_constant(js_undefined()));
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
generate_optional_chain(generator, *this, current_value, current_base);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return current_value;
LibJS/Bytecode: Implement optional chaining
2023-06-17 14:50:23 +01:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> ImportCall::generate_bytecode(Bytecode::Generator& generator, Optional<ScopedOperand> preferred_dst) const
LibJS/Bytecode: Add codegen for ImportCall Also moved most of the AST ImportCall::execute() into a helper so we can share the code.
2023-06-24 15:22:16 +02:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto specifier = m_specifier->generate_bytecode(generator).value();
LibJS/Bytecode: Add codegen for ImportCall Also moved most of the AST ImportCall::execute() into a helper so we can share the code.
2023-06-24 15:22:16 +02:00
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
Optional<ScopedOperand> options;
LibJS/Bytecode: Add codegen for ImportCall Also moved most of the AST ImportCall::execute() into a helper so we can share the code.
2023-06-24 15:22:16 +02:00
if (m_options) {
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
options = m_options->generate_bytecode(generator).value();
LibJS/Bytecode: Add codegen for ImportCall Also moved most of the AST ImportCall::execute() into a helper so we can share the code.
2023-06-24 15:22:16 +02:00
} else {
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
options = generator.add_constant(js_undefined());
LibJS/Bytecode: Add codegen for ImportCall Also moved most of the AST ImportCall::execute() into a helper so we can share the code.
2023-06-24 15:22:16 +02:00
}
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
auto dst = choose_dst(generator, preferred_dst);
generator.emit<Bytecode::Op::ImportCall>(dst, specifier, *options);
return dst;
LibJS/Bytecode: Add codegen for ImportCall Also moved most of the AST ImportCall::execute() into a helper so we can share the code.
2023-06-24 15:22:16 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> ExportStatement::generate_bytecode(Bytecode::Generator& generator, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS/Bytecode: Add some basic codegen for ExportStatement This is by no means complete, but at least a bunch of test-js and test262 tests start working. :^)
2023-06-24 16:07:43 +02:00
{
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 16:53:55 +02:00
Bytecode::Generator::SourceLocationScope scope(generator, *this);
LibJS/Bytecode: Add some basic codegen for ExportStatement This is by no means complete, but at least a bunch of test-js and test262 tests start working. :^)
2023-06-24 16:07:43 +02:00
if (!is_default_export()) {
if (m_statement) {
return m_statement->generate_bytecode(generator);
}
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
return Optional<ScopedOperand> {};
LibJS/Bytecode: Add some basic codegen for ExportStatement This is by no means complete, but at least a bunch of test-js and test262 tests start working. :^)
2023-06-24 16:07:43 +02:00
}
VERIFY(m_statement);
if (is<FunctionDeclaration>(*m_statement) || is<ClassDeclaration>(*m_statement)) {
return m_statement->generate_bytecode(generator);
}
// ExportDeclaration : export default AssignmentExpression ;
LibJS: Fix export default of parenthesized named class expression For `export default (class Name { })`, two things were wrong: The parser extracted the class expression's name as the export's local binding name instead of `*default*`. Per the spec, this is `export default AssignmentExpression ;` whose BoundNames is `*default*`, not the class name. The bytecode generator had a special case for ClassExpression that skipped emitting InitializeLexicalBinding for named classes. These two bugs compensated for each other (no crash, but wrong behavior). Fix both: always use `*default*` as the local binding name for expression exports, and always emit InitializeLexicalBinding for the `*default*` binding.
2026-02-21 16:20:36 +01:00
// Always initialize the *default* binding per step 5 of the spec.
LibJS/Bytecode: Add some basic codegen for ExportStatement This is by no means complete, but at least a bunch of test-js and test262 tests start working. :^)
2023-06-24 16:07:43 +02:00
VERIFY(is<Expression>(*m_statement));
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
auto value = generator.emit_named_evaluation_if_anonymous_function(static_cast<Expression const&>(*m_statement), generator.intern_identifier("default"_utf16_fly_string));
LibJS/Bytecode: Split SetVariable into four separate instructions Instead of SetVariable having 2x2 modes for variable/lexical and initialize/set, those 4 modes are now separate instructions, which makes each instruction much less branchy.
2024-05-14 11:30:30 +02:00
generator.emit<Bytecode::Op::InitializeLexicalBinding>(
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
generator.intern_identifier(ExportStatement::local_name_for_default),
LibJS/Bytecode: Split SetVariable into four separate instructions Instead of SetVariable having 2x2 modes for variable/lexical and initialize/set, those 4 modes are now separate instructions, which makes each instruction much less branchy.
2024-05-14 11:30:30 +02:00
value);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
return value;
LibJS/Bytecode: Add some basic codegen for ExportStatement This is by no means complete, but at least a bunch of test-js and test262 tests start working. :^)
2023-06-24 16:07:43 +02:00
}
LibJS: Make bytecode generation infallible Remove CodeGenerationError and make all bytecode generation functions return their results directly instead of wrapping them in CodeGenerationErrorOr. For the few remaining sites where codegen encounters an unimplemented or unexpected AST node, we now use a new emit_todo() helper that emits a NewTypeError + Throw sequence at compile time (preserving the runtime behavior) and then switches to a dead basic block so subsequent codegen for the same function can continue without issue. This allows us to remove error handling from all callers of the bytecode compiler, simplifying the code significantly.
2026-02-11 22:42:53 +01:00
Optional<ScopedOperand> ImportStatement::generate_bytecode(Bytecode::Generator&, [[maybe_unused]] Optional<ScopedOperand> preferred_dst) const
LibJS/Bytecode: Handle ImportStatement in codegen There is nothing to do here at runtime as imports are handled in `Interpreter::run`.
2023-06-27 20:46:41 +02:00
{
LibJS/Bytecode: Reuse bytecode registers This patch adds a register freelist to Bytecode::Generator and switches all operands inside the generator to a new ScopedOperand type that is ref-counted and automatically frees the register when nothing uses it. This dramatically reduces the size of bytecode executable register windows, which were often in the several thousands of registers for large functions. Most functions now use less than 100 registers.
2024-05-07 21:36:56 +02:00
return Optional<ScopedOperand> {};
LibJS/Bytecode: Handle ImportStatement in codegen There is nothing to do here at runtime as imports are handled in `Interpreter::run`.
2023-06-27 20:46:41 +02:00
}
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
}
Reference in a new issue Copy permalink