Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-31 05:10:57 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Userland/Libraries/LibJS/Bytecode/Generator.cpp

1244 lines
52 KiB
C++
Raw Normal View History

LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +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
* Copyright (c) 2021-2024, Andreas Kling <kling@serenityos.org>
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
LibJS/Bytecode: Flatten bytecode to a contiguous representation Instead of keeping bytecode as a set of disjoint basic blocks on the malloc heap, bytecode is now a contiguous sequence of bytes(!) The transformation happens at the end of Bytecode::Generator::generate() and the only really hairy part is rerouting jump labels. This required solving a few problems: - The interpreter execution loop had to change quite a bit, since we were storing BasicBlock pointers all over the place, and control transfer was done by redirecting the interpreter's current block. - Exception handlers & finalizers are now stored per-bytecode-range in a side table in Executable. - The interpreter now has a plain program counter instead of a stream iterator. This actually makes error stack generation a bit nicer since we just have to deal with a number instead of reaching into the iterator. This yields a 25% performance improvement on this microbenchmark: for (let i = 0; i < 1_000_000; ++i) { } But basically everything gets faster. :^)
2024-05-06 06:44:08 +02:00
#include <AK/QuickSort.h>
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
#include <AK/TemporaryChange.h>
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
#include <LibJS/AST.h>
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
#include <LibJS/Bytecode/BasicBlock.h>
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
#include <LibJS/Bytecode/Generator.h>
#include <LibJS/Bytecode/Instruction.h>
LibJS: Automatically split linear bytecode into multiple blocks ...instead of crashing :^)
2021-06-11 01:35:01 +04:30
#include <LibJS/Bytecode/Op.h>
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
#include <LibJS/Bytecode/Register.h>
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
#include <LibJS/Runtime/ECMAScriptFunctionObject.h>
LibJS: Make Bytecode::Executable GC-allocated This is a step towards making ExecutionContext easier to allocate.
2023-11-27 13:23:59 +01:00
#include <LibJS/Runtime/VM.h>
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
namespace JS::Bytecode {
LibJS/Bytecode: Make Generator aware of the function it's compiling
2024-05-31 20:32:29 +02:00
Generator::Generator(VM& vm, GCPtr<ECMAScriptFunctionObject const> function, MustPropagateCompletion must_propagate_completion)
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
: m_vm(vm)
, m_string_table(make<StringTable>())
LibJS: Add a separate "identifier table" to bytecode executables This is a specialized string table for storing identifiers only. Identifiers are always FlyStrings, which makes many common operations faster by allowing O(1) comparison.
2021-10-24 15:34:30 +02:00
, m_identifier_table(make<IdentifierTable>())
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
, m_regex_table(make<RegexTable>())
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
, m_constants(vm.heap())
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
, m_accumulator(*this, Operand(Register::accumulator()))
LibJS/Bytecode: Always resolve `this` binding into dedicated register We already have a dedicated register slot for `this`, so instead of having ResolveThisBinding take a `dst` operand, just write the value directly into the `this` register every time.
2024-05-31 20:41:29 +02:00
, m_this_value(*this, Operand(Register::this_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
, m_must_propagate_completion(must_propagate_completion == MustPropagateCompletion::Yes)
LibJS/Bytecode: Make Generator aware of the function it's compiling
2024-05-31 20:32:29 +02:00
, m_function(function)
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
{
}
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
CodeGenerationErrorOr<void> Generator::emit_function_declaration_instantiation(ECMAScriptFunctionObject const& function)
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
{
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
if (function.m_has_parameter_expressions) {
emit<Op::CreateLexicalEnvironment>();
}
for (auto const& parameter_name : function.m_parameter_names) {
if (parameter_name.value == ECMAScriptFunctionObject::ParameterIsLocal::No) {
auto id = intern_identifier(parameter_name.key);
emit<Op::CreateVariable>(id, Op::EnvironmentMode::Lexical, false);
if (function.m_has_duplicates) {
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
emit<Op::InitializeLexicalBinding>(id, add_constant(js_undefined()));
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
}
}
}
if (function.m_arguments_object_needed) {
LibJS: Use a local variable for arguments object when possible This allows us to skip allocating a function environment in cases where it was previously impossible because the arguments object needed a binding. This change does not bring visible improvement in Kraken or Octane benchmarks but seems useful to have anyway.
2024-05-21 09:32:51 +01:00
Optional<Operand> dst;
auto local_var_index = function.m_local_variables_names.find_first_index("arguments"sv);
if (local_var_index.has_value())
dst = local(local_var_index.value());
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
if (function.m_strict || !function.has_simple_parameter_list()) {
LibJS: Use a local variable for arguments object when possible This allows us to skip allocating a function environment in cases where it was previously impossible because the arguments object needed a binding. This change does not bring visible improvement in Kraken or Octane benchmarks but seems useful to have anyway.
2024-05-21 09:32:51 +01:00
emit<Op::CreateArguments>(dst, Op::CreateArguments::Kind::Unmapped, function.m_strict);
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
} else {
LibJS: Use a local variable for arguments object when possible This allows us to skip allocating a function environment in cases where it was previously impossible because the arguments object needed a binding. This change does not bring visible improvement in Kraken or Octane benchmarks but seems useful to have anyway.
2024-05-21 09:32:51 +01:00
emit<Op::CreateArguments>(dst, Op::CreateArguments::Kind::Mapped, function.m_strict);
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
}
}
auto const& formal_parameters = function.formal_parameters();
for (u32 param_index = 0; param_index < formal_parameters.size(); ++param_index) {
auto const& parameter = formal_parameters[param_index];
if (parameter.is_rest) {
auto argument_reg = allocate_register();
emit<Op::CreateRestParams>(argument_reg.operand(), param_index);
emit<Op::SetArgument>(param_index, argument_reg.operand());
} else if (parameter.default_value) {
auto& if_undefined_block = make_block();
auto& if_not_undefined_block = make_block();
auto argument_reg = allocate_register();
emit<Op::GetArgument>(argument_reg.operand(), param_index);
emit<Op::JumpUndefined>(
argument_reg.operand(),
Label { if_undefined_block },
Label { if_not_undefined_block });
switch_to_basic_block(if_undefined_block);
auto operand = TRY(parameter.default_value->generate_bytecode(*this));
emit<Op::SetArgument>(param_index, *operand);
emit<Op::Jump>(Label { if_not_undefined_block });
switch_to_basic_block(if_not_undefined_block);
}
if (auto const* identifier = parameter.binding.get_pointer<NonnullRefPtr<Identifier const>>(); identifier) {
if ((*identifier)->is_local()) {
auto local_variable_index = (*identifier)->local_variable_index();
emit<Op::GetArgument>(local(local_variable_index), param_index);
set_local_initialized((*identifier)->local_variable_index());
} else {
auto id = intern_identifier((*identifier)->string());
auto argument_reg = allocate_register();
emit<Op::GetArgument>(argument_reg.operand(), param_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
if (function.m_has_duplicates) {
emit<Op::SetLexicalBinding>(id, argument_reg.operand());
} else {
emit<Op::InitializeLexicalBinding>(id, argument_reg.operand());
}
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
}
} else if (auto const* binding_pattern = parameter.binding.get_pointer<NonnullRefPtr<BindingPattern const>>(); binding_pattern) {
auto input_operand = allocate_register();
emit<Op::GetArgument>(input_operand.operand(), param_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
auto init_mode = function.m_has_duplicates ? Op::BindingInitializationMode::Set : Bytecode::Op::BindingInitializationMode::Initialize;
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
TRY((*binding_pattern)->generate_bytecode(*this, init_mode, input_operand, false));
}
}
ScopeNode const* scope_body = nullptr;
if (is<ScopeNode>(*function.m_ecmascript_code))
scope_body = static_cast<ScopeNode const*>(function.m_ecmascript_code.ptr());
if (!function.m_has_parameter_expressions) {
if (scope_body) {
for (auto const& variable_to_initialize : function.m_var_names_to_initialize_binding) {
auto const& id = variable_to_initialize.identifier;
if (id.is_local()) {
emit<Op::Mov>(local(id.local_variable_index()), add_constant(js_undefined()));
} else {
auto intern_id = intern_identifier(id.string());
emit<Op::CreateVariable>(intern_id, Op::EnvironmentMode::Var, false);
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
emit<Op::InitializeVariableBinding>(intern_id, add_constant(js_undefined()));
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
}
}
}
} else {
LibJS: Ensure capacity for created lexical and variable environments If the minimal amount of required bindings is known in advance, it could be used to ensure capacity to avoid resizing the internal vector that holds bindings.
2024-05-09 17:10:20 +02:00
emit<Op::CreateVariableEnvironment>(function.m_var_environment_bindings_count);
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
if (scope_body) {
for (auto const& variable_to_initialize : function.m_var_names_to_initialize_binding) {
auto const& id = variable_to_initialize.identifier;
auto initial_value = allocate_register();
if (!variable_to_initialize.parameter_binding || variable_to_initialize.function_name) {
emit<Op::Mov>(initial_value, add_constant(js_undefined()));
} else {
if (id.is_local()) {
emit<Op::Mov>(initial_value, local(id.local_variable_index()));
} else {
LibJS/Bytecode: Rename GetVariable => GetBinding
2024-05-14 11:32:04 +02:00
emit<Op::GetBinding>(initial_value, intern_identifier(id.string()));
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
}
}
if (id.is_local()) {
emit<Op::Mov>(local(id.local_variable_index()), initial_value);
} else {
auto intern_id = intern_identifier(id.string());
emit<Op::CreateVariable>(intern_id, Op::EnvironmentMode::Var, false);
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
emit<Op::InitializeVariableBinding>(intern_id, initial_value);
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +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: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
if (!function.m_strict && scope_body) {
for (auto const& function_name : function.m_function_names_to_initialize_binding) {
auto intern_id = intern_identifier(function_name);
emit<Op::CreateVariable>(intern_id, Op::EnvironmentMode::Var, false);
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
emit<Op::InitializeVariableBinding>(intern_id, 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
}
}
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
if (!function.m_strict) {
bool can_elide_declarative_environment = !function.m_contains_direct_call_to_eval && (!scope_body || !scope_body->has_non_local_lexical_declarations());
if (!can_elide_declarative_environment) {
LibJS: Ensure capacity for created lexical and variable environments If the minimal amount of required bindings is known in advance, it could be used to ensure capacity to avoid resizing the internal vector that holds bindings.
2024-05-09 17:10:20 +02:00
emit<Op::CreateLexicalEnvironment>(function.m_lex_environment_bindings_count);
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
}
}
if (scope_body) {
MUST(scope_body->for_each_lexically_scoped_declaration([&](Declaration const& declaration) {
MUST(declaration.for_each_bound_identifier([&](auto const& id) {
if (id.is_local()) {
return;
}
emit<Op::CreateVariable>(intern_identifier(id.string()),
Op::EnvironmentMode::Lexical,
declaration.is_constant_declaration(),
false,
declaration.is_constant_declaration());
}));
}));
}
for (auto const& declaration : function.m_functions_to_initialize) {
auto function = allocate_register();
emit<Op::NewFunction>(function, declaration, OptionalNone {});
if (declaration.name_identifier()->is_local()) {
emit<Op::Mov>(local(declaration.name_identifier()->local_variable_index()), function);
} else {
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
emit<Op::SetVariableBinding>(intern_identifier(declaration.name()), function);
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
}
}
return {};
}
LibJS/Bytecode: Display local variable names in bytecode dumps Instead of displaying locals as "locN", we now show them as "name~N". This makes it a lot easier to follow bytecode dumps, especially in longer functions. Note that we keep displaying the local index, to avoid confusion in case there are multiple separate locals with the same name in one executable.
2024-06-13 21:19:06 +02:00
CodeGenerationErrorOr<NonnullGCPtr<Executable>> Generator::compile(VM& vm, ASTNode const& node, FunctionKind enclosing_function_kind, GCPtr<ECMAScriptFunctionObject const> function, MustPropagateCompletion must_propagate_completion, Vector<DeprecatedFlyString> local_variable_names)
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
{
LibJS/Bytecode: Make Generator aware of the function it's compiling
2024-05-31 20:32:29 +02:00
Generator generator(vm, function, must_propagate_completion);
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +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(generator.make_block());
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
SourceLocationScope scope(generator, node);
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.m_enclosing_function_kind = enclosing_function_kind;
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
if (generator.is_in_async_function() && !generator.is_in_generator_function()) {
// Immediately yield with no value.
auto& start_block = generator.make_block();
generator.emit<Bytecode::Op::Yield>(Label { start_block }, generator.add_constant(js_undefined()));
generator.switch_to_basic_block(start_block);
// NOTE: This doesn't have to handle received throw/return completions, as GeneratorObject::resume_abrupt
// will not enter the generator from the SuspendedStart state and immediately completes the generator.
}
if (function)
TRY(generator.emit_function_declaration_instantiation(*function));
if (generator.is_in_generator_function()) {
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
// Immediately yield with no value.
auto& start_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>(Label { start_block }, generator.add_constant(js_undefined()));
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
generator.switch_to_basic_block(start_block);
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
// NOTE: This doesn't have to handle received throw/return completions, as GeneratorObject::resume_abrupt
// will not enter the generator from the SuspendedStart state and immediately completes the generator.
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
auto last_value = TRY(node.generate_bytecode(generator));
if (!generator.current_block().is_terminated() && last_value.has_value()) {
generator.emit<Bytecode::Op::End>(last_value.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
if (generator.is_in_generator_or_async_function()) {
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
// Terminate all unterminated blocks with yield return
for (auto& block : generator.m_root_basic_blocks) {
Everywhere: Stop using NonnullOwnPtrVector Same as NonnullRefPtrVector: weird semantics, questionable benefits.
2023-03-06 17:16:25 +01:00
if (block->is_terminated())
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
continue;
Everywhere: Stop using NonnullOwnPtrVector Same as NonnullRefPtrVector: weird semantics, questionable benefits.
2023-03-06 17:16:25 +01:00
generator.switch_to_basic_block(*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>(generator.add_constant(js_undefined()));
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
}
}
LibJS/Bytecode: Determine strict mode on an executable basis An executable is generated for the top-level script and for each function. Strict mode can only be changed with the first statement of the top-level script and each function, which corresponds directly to Executable.
2022-07-17 18:56:36 +01:00
bool is_strict_mode = false;
if (is<Program>(node))
is_strict_mode = static_cast<Program const&>(node).is_strict_mode();
else if (is<FunctionBody>(node))
is_strict_mode = static_cast<FunctionBody const&>(node).in_strict_mode();
else if (is<FunctionDeclaration>(node))
is_strict_mode = static_cast<FunctionDeclaration const&>(node).is_strict_mode();
LibJS/Bytecode: Flatten bytecode to a contiguous representation Instead of keeping bytecode as a set of disjoint basic blocks on the malloc heap, bytecode is now a contiguous sequence of bytes(!) The transformation happens at the end of Bytecode::Generator::generate() and the only really hairy part is rerouting jump labels. This required solving a few problems: - The interpreter execution loop had to change quite a bit, since we were storing BasicBlock pointers all over the place, and control transfer was done by redirecting the interpreter's current block. - Exception handlers & finalizers are now stored per-bytecode-range in a side table in Executable. - The interpreter now has a plain program counter instead of a stream iterator. This actually makes error stack generation a bit nicer since we just have to deal with a number instead of reaching into the iterator. This yields a 25% performance improvement on this microbenchmark: for (let i = 0; i < 1_000_000; ++i) { } But basically everything gets faster. :^)
2024-05-06 06:44:08 +02:00
size_t size_needed = 0;
for (auto& block : generator.m_root_basic_blocks) {
size_needed += block->size();
}
Vector<u8> bytecode;
bytecode.ensure_capacity(size_needed);
Vector<size_t> basic_block_start_offsets;
basic_block_start_offsets.ensure_capacity(generator.m_root_basic_blocks.size());
HashMap<BasicBlock const*, size_t> block_offsets;
Vector<size_t> label_offsets;
struct UnlinkedExceptionHandlers {
size_t start_offset;
size_t end_offset;
BasicBlock const* handler;
BasicBlock const* finalizer;
};
Vector<UnlinkedExceptionHandlers> unlinked_exception_handlers;
LibJS/Bytecode: Keep instruction source mappings in Executable Instead of storing source offsets with each instruction, we now keep them in a side table in Executable. This shrinks each instruction by 8 bytes, further improving locality.
2024-05-06 07:51:14 +02:00
HashMap<size_t, SourceRecord> source_map;
LibJS/Bytecode: Move bytecode operand rewriting to a separate pass This way we don't have to do it whenever performing some kind of instruction rewrite.
2024-06-01 10:19:28 +02:00
Optional<ScopedOperand> undefined_constant;
LibJS: Join locals, constants and registers into single vector Merging registers, constants and locals into single vector means: - Better data locality - No need to check type in Interpreter::get() and Interpreter::set() which are very hot functions Performance improvement is visible in almost all Octane and Kraken tests.
2024-05-12 18:49:03 +02:00
for (auto& block : generator.m_root_basic_blocks) {
if (!block->is_terminated()) {
// NOTE: We must ensure that the "undefined" constant, which will be used by the not yet
// emitted End instruction, is taken into account while shifting local operands by the
// number of constants.
LibJS/Bytecode: Move bytecode operand rewriting to a separate pass This way we don't have to do it whenever performing some kind of instruction rewrite.
2024-06-01 10:19:28 +02:00
undefined_constant = generator.add_constant(js_undefined());
LibJS: Join locals, constants and registers into single vector Merging registers, constants and locals into single vector means: - Better data locality - No need to check type in Interpreter::get() and Interpreter::set() which are very hot functions Performance improvement is visible in almost all Octane and Kraken tests.
2024-05-12 18:49:03 +02:00
break;
}
}
auto number_of_registers = generator.m_next_register;
auto number_of_constants = generator.m_constants.size();
LibJS/Bytecode: Move bytecode operand rewriting to a separate pass This way we don't have to do it whenever performing some kind of instruction rewrite.
2024-06-01 10:19:28 +02:00
// Pass: Rewrite the bytecode to use the correct register and constant indices.
for (auto& block : generator.m_root_basic_blocks) {
Bytecode::InstructionStreamIterator it(block->instruction_stream());
while (!it.at_end()) {
auto& instruction = const_cast<Instruction&>(*it);
instruction.visit_operands([number_of_registers, number_of_constants](Operand& operand) {
switch (operand.type()) {
case Operand::Type::Register:
break;
case Operand::Type::Local:
operand.offset_index_by(number_of_registers + number_of_constants);
break;
case Operand::Type::Constant:
operand.offset_index_by(number_of_registers);
break;
default:
VERIFY_NOT_REACHED();
}
});
++it;
}
}
// Also rewrite the `undefined` constant if we have one for inserting End.
if (undefined_constant.has_value())
undefined_constant.value().operand().offset_index_by(number_of_registers);
LibJS/Bytecode: Flatten bytecode to a contiguous representation Instead of keeping bytecode as a set of disjoint basic blocks on the malloc heap, bytecode is now a contiguous sequence of bytes(!) The transformation happens at the end of Bytecode::Generator::generate() and the only really hairy part is rerouting jump labels. This required solving a few problems: - The interpreter execution loop had to change quite a bit, since we were storing BasicBlock pointers all over the place, and control transfer was done by redirecting the interpreter's current block. - Exception handlers & finalizers are now stored per-bytecode-range in a side table in Executable. - The interpreter now has a plain program counter instead of a stream iterator. This actually makes error stack generation a bit nicer since we just have to deal with a number instead of reaching into the iterator. This yields a 25% performance improvement on this microbenchmark: for (let i = 0; i < 1_000_000; ++i) { } But basically everything gets faster. :^)
2024-05-06 06:44:08 +02:00
for (auto& block : generator.m_root_basic_blocks) {
basic_block_start_offsets.append(bytecode.size());
if (block->handler() || block->finalizer()) {
unlinked_exception_handlers.append({
.start_offset = bytecode.size(),
.end_offset = 0,
.handler = block->handler(),
.finalizer = block->finalizer(),
});
}
block_offsets.set(block.ptr(), bytecode.size());
LibJS/Bytecode: Keep instruction source mappings in Executable Instead of storing source offsets with each instruction, we now keep them in a side table in Executable. This shrinks each instruction by 8 bytes, further improving locality.
2024-05-06 07:51:14 +02:00
for (auto& [offset, source_record] : block->source_map()) {
source_map.set(bytecode.size() + offset, source_record);
}
LibJS/Bytecode: Flatten bytecode to a contiguous representation Instead of keeping bytecode as a set of disjoint basic blocks on the malloc heap, bytecode is now a contiguous sequence of bytes(!) The transformation happens at the end of Bytecode::Generator::generate() and the only really hairy part is rerouting jump labels. This required solving a few problems: - The interpreter execution loop had to change quite a bit, since we were storing BasicBlock pointers all over the place, and control transfer was done by redirecting the interpreter's current block. - Exception handlers & finalizers are now stored per-bytecode-range in a side table in Executable. - The interpreter now has a plain program counter instead of a stream iterator. This actually makes error stack generation a bit nicer since we just have to deal with a number instead of reaching into the iterator. This yields a 25% performance improvement on this microbenchmark: for (let i = 0; i < 1_000_000; ++i) { } But basically everything gets faster. :^)
2024-05-06 06:44:08 +02:00
Bytecode::InstructionStreamIterator it(block->instruction_stream());
while (!it.at_end()) {
auto& instruction = const_cast<Instruction&>(*it);
LibJS/Bytecode: Elide jumps that land in the very next block Jumping to the next block is effectively a no-op, so let's save time and space by just not emitting those jumps.
2024-05-06 09:33:53 +02:00
if (instruction.type() == Instruction::Type::Jump) {
auto& jump = static_cast<Bytecode::Op::Jump&>(instruction);
LibJS/Bytecode: Rewrite Jump-to-Return-or-End as just Return or End Instead of wasting time jumping to a shared Return or End instruction, we can also emit a Return or End directly in many cases.
2024-06-01 10:20:12 +02:00
// OPTIMIZATION: Don't emit jumps that just jump to the next block.
LibJS/Bytecode: Elide jumps that land in the very next block Jumping to the next block is effectively a no-op, so let's save time and space by just not emitting those jumps.
2024-05-06 09:33:53 +02:00
if (jump.target().basic_block_index() == block->index() + 1) {
if (basic_block_start_offsets.last() == bytecode.size()) {
// This block is empty, just skip it.
basic_block_start_offsets.take_last();
}
++it;
continue;
}
LibJS/Bytecode: Rewrite Jump-to-Return-or-End as just Return or End Instead of wasting time jumping to a shared Return or End instruction, we can also emit a Return or End directly in many cases.
2024-06-01 10:20:12 +02:00
// OPTIMIZATION: For jumps to a return-or-end-only block, we can emit a `Return` or `End` directly instead.
auto& target_block = *generator.m_root_basic_blocks[jump.target().basic_block_index()];
if (target_block.is_terminated()) {
auto target_instruction_iterator = InstructionStreamIterator { target_block.instruction_stream() };
auto& target_instruction = *target_instruction_iterator;
if (target_instruction.type() == Instruction::Type::Return) {
auto& return_instruction = static_cast<Bytecode::Op::Return const&>(target_instruction);
Op::Return return_op(return_instruction.value());
bytecode.append(reinterpret_cast<u8 const*>(&return_op), return_op.length());
++it;
continue;
}
if (target_instruction.type() == Instruction::Type::End) {
auto& return_instruction = static_cast<Bytecode::Op::End const&>(target_instruction);
Op::End end_op(return_instruction.value());
bytecode.append(reinterpret_cast<u8 const*>(&end_op), end_op.length());
++it;
continue;
}
}
LibJS/Bytecode: Elide jumps that land in the very next block Jumping to the next block is effectively a no-op, so let's save time and space by just not emitting those jumps.
2024-05-06 09:33:53 +02:00
}
LibJS/Bytecode: Turn JumpIf condition,@a,@next into JumpTrue/JumpFalse If one of the jump targets is the very next block, we can convert the jump instruction into a smaller JumpTrue or JumpFalse.
2024-05-06 10:15:17 +02:00
// OPTIMIZATION: For `JumpIf` where one of the targets is the very next block,
// we can emit a `JumpTrue` or `JumpFalse` (to the other block) instead.
if (instruction.type() == Instruction::Type::JumpIf) {
auto& jump = static_cast<Bytecode::Op::JumpIf&>(instruction);
if (jump.true_target().basic_block_index() == block->index() + 1) {
Op::JumpFalse jump_false(jump.condition(), Label { jump.false_target() });
auto& label = jump_false.target();
size_t label_offset = bytecode.size() + (bit_cast<FlatPtr>(&label) - bit_cast<FlatPtr>(&jump_false));
label_offsets.append(label_offset);
bytecode.append(reinterpret_cast<u8 const*>(&jump_false), jump_false.length());
++it;
continue;
}
if (jump.false_target().basic_block_index() == block->index() + 1) {
Op::JumpTrue jump_true(jump.condition(), Label { jump.true_target() });
auto& label = jump_true.target();
size_t label_offset = bytecode.size() + (bit_cast<FlatPtr>(&label) - bit_cast<FlatPtr>(&jump_true));
label_offsets.append(label_offset);
bytecode.append(reinterpret_cast<u8 const*>(&jump_true), jump_true.length());
++it;
continue;
}
}
LibJS/Bytecode: Flatten bytecode to a contiguous representation Instead of keeping bytecode as a set of disjoint basic blocks on the malloc heap, bytecode is now a contiguous sequence of bytes(!) The transformation happens at the end of Bytecode::Generator::generate() and the only really hairy part is rerouting jump labels. This required solving a few problems: - The interpreter execution loop had to change quite a bit, since we were storing BasicBlock pointers all over the place, and control transfer was done by redirecting the interpreter's current block. - Exception handlers & finalizers are now stored per-bytecode-range in a side table in Executable. - The interpreter now has a plain program counter instead of a stream iterator. This actually makes error stack generation a bit nicer since we just have to deal with a number instead of reaching into the iterator. This yields a 25% performance improvement on this microbenchmark: for (let i = 0; i < 1_000_000; ++i) { } But basically everything gets faster. :^)
2024-05-06 06:44:08 +02:00
instruction.visit_labels([&](Label& label) {
size_t label_offset = bytecode.size() + (bit_cast<FlatPtr>(&label) - bit_cast<FlatPtr>(&instruction));
label_offsets.append(label_offset);
});
bytecode.append(reinterpret_cast<u8 const*>(&instruction), instruction.length());
++it;
}
if (!block->is_terminated()) {
LibJS/Bytecode: Move bytecode operand rewriting to a separate pass This way we don't have to do it whenever performing some kind of instruction rewrite.
2024-06-01 10:19:28 +02:00
Op::End end(*undefined_constant);
LibJS/Bytecode: Flatten bytecode to a contiguous representation Instead of keeping bytecode as a set of disjoint basic blocks on the malloc heap, bytecode is now a contiguous sequence of bytes(!) The transformation happens at the end of Bytecode::Generator::generate() and the only really hairy part is rerouting jump labels. This required solving a few problems: - The interpreter execution loop had to change quite a bit, since we were storing BasicBlock pointers all over the place, and control transfer was done by redirecting the interpreter's current block. - Exception handlers & finalizers are now stored per-bytecode-range in a side table in Executable. - The interpreter now has a plain program counter instead of a stream iterator. This actually makes error stack generation a bit nicer since we just have to deal with a number instead of reaching into the iterator. This yields a 25% performance improvement on this microbenchmark: for (let i = 0; i < 1_000_000; ++i) { } But basically everything gets faster. :^)
2024-05-06 06:44:08 +02:00
bytecode.append(reinterpret_cast<u8 const*>(&end), end.length());
}
if (block->handler() || block->finalizer()) {
unlinked_exception_handlers.last().end_offset = bytecode.size();
}
}
for (auto label_offset : label_offsets) {
auto& label = *reinterpret_cast<Label*>(bytecode.data() + label_offset);
LibJS/Bytecode: Store labels as basic block index during compilation Instead of storing a BasicBlock* and forcing the size of Label to be sizeof(BasicBlock*), we now store the basic block index as a u32. This means the final version of the bytecode is able to keep labels at sizeof(u32), shrinking the size of many instructions. :^)
2024-05-06 08:06:56 +02:00
auto* block = generator.m_root_basic_blocks[label.basic_block_index()].ptr();
LibJS/Bytecode: Flatten bytecode to a contiguous representation Instead of keeping bytecode as a set of disjoint basic blocks on the malloc heap, bytecode is now a contiguous sequence of bytes(!) The transformation happens at the end of Bytecode::Generator::generate() and the only really hairy part is rerouting jump labels. This required solving a few problems: - The interpreter execution loop had to change quite a bit, since we were storing BasicBlock pointers all over the place, and control transfer was done by redirecting the interpreter's current block. - Exception handlers & finalizers are now stored per-bytecode-range in a side table in Executable. - The interpreter now has a plain program counter instead of a stream iterator. This actually makes error stack generation a bit nicer since we just have to deal with a number instead of reaching into the iterator. This yields a 25% performance improvement on this microbenchmark: for (let i = 0; i < 1_000_000; ++i) { } But basically everything gets faster. :^)
2024-05-06 06:44:08 +02:00
label.set_address(block_offsets.get(block).value());
}
LibJS: Make Bytecode::Executable GC-allocated This is a step towards making ExecutionContext easier to allocate.
2023-11-27 13:23:59 +01:00
auto executable = vm.heap().allocate_without_realm<Executable>(
LibJS/Bytecode: Flatten bytecode to a contiguous representation Instead of keeping bytecode as a set of disjoint basic blocks on the malloc heap, bytecode is now a contiguous sequence of bytes(!) The transformation happens at the end of Bytecode::Generator::generate() and the only really hairy part is rerouting jump labels. This required solving a few problems: - The interpreter execution loop had to change quite a bit, since we were storing BasicBlock pointers all over the place, and control transfer was done by redirecting the interpreter's current block. - Exception handlers & finalizers are now stored per-bytecode-range in a side table in Executable. - The interpreter now has a plain program counter instead of a stream iterator. This actually makes error stack generation a bit nicer since we just have to deal with a number instead of reaching into the iterator. This yields a 25% performance improvement on this microbenchmark: for (let i = 0; i < 1_000_000; ++i) { } But basically everything gets faster. :^)
2024-05-06 06:44:08 +02:00
move(bytecode),
LibJS: Make Executable ref-counted and let instruction iterator co-own it This ensures that the instruction stream pointed at by the instruction iterator remains valid as long as the iterator exists.
2023-10-03 08:18:10 +02:00
move(generator.m_identifier_table),
move(generator.m_string_table),
move(generator.m_regex_table),
LibJS/Bytecode: Add constants table to Bytecode::Executable
2024-02-02 09:52:25 +01:00
move(generator.m_constants),
LibJS: Make Executable ref-counted and let instruction iterator co-own it This ensures that the instruction stream pointed at by the instruction iterator remains valid as long as the iterator exists.
2023-10-03 08:18:10 +02:00
node.source_code(),
generator.m_next_property_lookup_cache,
generator.m_next_global_variable_cache,
generator.m_next_register,
LibJS: Make Bytecode::Executable GC-allocated This is a step towards making ExecutionContext easier to allocate.
2023-11-27 13:23:59 +01:00
is_strict_mode);
LibJS/Bytecode: Cache object own property accesses The instructions GetById and GetByIdWithThis now remember the last-seen Shape, and if we see the same object again, we reuse the property offset from last time without doing a new lookup. This allows us to use Object::get_direct(), bypassing the entire lookup machinery and saving lots of time. ~23% speed-up on Kraken/ai-astar.js :^)
2023-07-08 17:43:26 +02:00
LibJS/Bytecode: Flatten bytecode to a contiguous representation Instead of keeping bytecode as a set of disjoint basic blocks on the malloc heap, bytecode is now a contiguous sequence of bytes(!) The transformation happens at the end of Bytecode::Generator::generate() and the only really hairy part is rerouting jump labels. This required solving a few problems: - The interpreter execution loop had to change quite a bit, since we were storing BasicBlock pointers all over the place, and control transfer was done by redirecting the interpreter's current block. - Exception handlers & finalizers are now stored per-bytecode-range in a side table in Executable. - The interpreter now has a plain program counter instead of a stream iterator. This actually makes error stack generation a bit nicer since we just have to deal with a number instead of reaching into the iterator. This yields a 25% performance improvement on this microbenchmark: for (let i = 0; i < 1_000_000; ++i) { } But basically everything gets faster. :^)
2024-05-06 06:44:08 +02:00
Vector<Executable::ExceptionHandlers> linked_exception_handlers;
for (auto& unlinked_handler : unlinked_exception_handlers) {
auto start_offset = unlinked_handler.start_offset;
auto end_offset = unlinked_handler.end_offset;
auto handler_offset = unlinked_handler.handler ? block_offsets.get(unlinked_handler.handler).value() : Optional<size_t> {};
auto finalizer_offset = unlinked_handler.finalizer ? block_offsets.get(unlinked_handler.finalizer).value() : Optional<size_t> {};
linked_exception_handlers.append({ start_offset, end_offset, handler_offset, finalizer_offset });
}
quick_sort(linked_exception_handlers, [](auto const& a, auto const& b) {
return a.start_offset < b.start_offset;
});
executable->exception_handlers = move(linked_exception_handlers);
executable->basic_block_start_offsets = move(basic_block_start_offsets);
LibJS/Bytecode: Keep instruction source mappings in Executable Instead of storing source offsets with each instruction, we now keep them in a side table in Executable. This shrinks each instruction by 8 bytes, further improving locality.
2024-05-06 07:51:14 +02:00
executable->source_map = move(source_map);
LibJS/Bytecode: Display local variable names in bytecode dumps Instead of displaying locals as "locN", we now show them as "name~N". This makes it a lot easier to follow bytecode dumps, especially in longer functions. Note that we keep displaying the local index, to avoid confusion in case there are multiple separate locals with the same name in one executable.
2024-06-13 21:19:06 +02:00
executable->local_variable_names = move(local_variable_names);
executable->local_index_base = number_of_registers + number_of_constants;
LibJS: Make GetById and GetByValue avoid get_identifier() in common case We now defer looking up the various identifiers by IdentifierTableIndex until the last moment. This allows us to avoid the retrieval in common cases like when a property access is cached. Knocks a ~12% item off the profile on https://ventrella.com/Clusters/
2024-07-09 11:37:06 +02:00
executable->length_identifier = generator.m_length_identifier;
LibJS/Bytecode: Flatten bytecode to a contiguous representation Instead of keeping bytecode as a set of disjoint basic blocks on the malloc heap, bytecode is now a contiguous sequence of bytes(!) The transformation happens at the end of Bytecode::Generator::generate() and the only really hairy part is rerouting jump labels. This required solving a few problems: - The interpreter execution loop had to change quite a bit, since we were storing BasicBlock pointers all over the place, and control transfer was done by redirecting the interpreter's current block. - Exception handlers & finalizers are now stored per-bytecode-range in a side table in Executable. - The interpreter now has a plain program counter instead of a stream iterator. This actually makes error stack generation a bit nicer since we just have to deal with a number instead of reaching into the iterator. This yields a 25% performance improvement on this microbenchmark: for (let i = 0; i < 1_000_000; ++i) { } But basically everything gets faster. :^)
2024-05-06 06:44:08 +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
generator.m_finished = true;
LibJS: Make Executable ref-counted and let instruction iterator co-own it This ensures that the instruction stream pointed at by the instruction iterator remains valid as long as the iterator exists.
2023-10-03 08:18:10 +02:00
return executable;
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
}
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
CodeGenerationErrorOr<NonnullGCPtr<Executable>> Generator::generate_from_ast_node(VM& vm, ASTNode const& node, FunctionKind enclosing_function_kind)
{
LibJS/Bytecode: Display local variable names in bytecode dumps Instead of displaying locals as "locN", we now show them as "name~N". This makes it a lot easier to follow bytecode dumps, especially in longer functions. Note that we keep displaying the local index, to avoid confusion in case there are multiple separate locals with the same name in one executable.
2024-06-13 21:19:06 +02:00
Vector<DeprecatedFlyString> local_variable_names;
if (is<ScopeNode>(node))
local_variable_names = static_cast<ScopeNode const&>(node).local_variables_names();
return compile(vm, node, enclosing_function_kind, {}, MustPropagateCompletion::Yes, move(local_variable_names));
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
}
CodeGenerationErrorOr<NonnullGCPtr<Executable>> Generator::generate_from_function(VM& vm, ECMAScriptFunctionObject const& function)
{
LibJS/Bytecode: Display local variable names in bytecode dumps Instead of displaying locals as "locN", we now show them as "name~N". This makes it a lot easier to follow bytecode dumps, especially in longer functions. Note that we keep displaying the local index, to avoid confusion in case there are multiple separate locals with the same name in one executable.
2024-06-13 21:19:06 +02:00
return compile(vm, function.ecmascript_code(), function.kind(), &function, MustPropagateCompletion::No, function.local_variables_names());
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 22:06:55 +02:00
}
Revert "LibJS: Add bytecode instruction handles" This reverts commit a01bd35c67e35e9f0e33f46bb3a4431e49af1b60. This broke simple programs like: function sum(a, b) { return a + b; } console.log(sum(1, 2));
2021-06-09 00:50:42 +02:00
void Generator::grow(size_t additional_size)
{
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
VERIFY(m_current_basic_block);
m_current_basic_block->grow(additional_size);
Revert "LibJS: Add bytecode instruction handles" This reverts commit a01bd35c67e35e9f0e33f46bb3a4431e49af1b60. This broke simple programs like: function sum(a, b) { return a + b; } console.log(sum(1, 2));
2021-06-09 00:50: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
ScopedOperand Generator::allocate_register()
{
if (!m_free_registers.is_empty()) {
return ScopedOperand { *this, Operand { m_free_registers.take_last() } };
}
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(m_next_register != NumericLimits<u32>::max());
return ScopedOperand { *this, Operand { Register { m_next_register++ } } };
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
}
void Generator::free_register(Register reg)
{
m_free_registers.append(reg);
}
ScopedOperand Generator::local(u32 local_index)
{
return ScopedOperand { *this, Operand { Operand::Type::Local, static_cast<u32>(local_index) } };
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46: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
Generator::SourceLocationScope::SourceLocationScope(Generator& generator, ASTNode const& node)
: m_generator(generator)
, m_previous_node(m_generator.m_current_ast_node)
{
m_generator.m_current_ast_node = &node;
}
Generator::SourceLocationScope::~SourceLocationScope()
{
m_generator.m_current_ast_node = m_previous_node;
}
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
Generator::UnwindContext::UnwindContext(Generator& generator, Optional<Label> finalizer)
: m_generator(generator)
, m_finalizer(finalizer)
, m_previous_context(m_generator.m_current_unwind_context)
{
m_generator.m_current_unwind_context = this;
}
Generator::UnwindContext::~UnwindContext()
{
VERIFY(m_generator.m_current_unwind_context == this);
m_generator.m_current_unwind_context = m_previous_context;
}
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
Label Generator::nearest_continuable_scope() 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
return m_continuable_scopes.last().bytecode_target;
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/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 Generator::emit_block_declaration_instantiation(ScopeNode const& scope_node)
LibJS/Bytecode: Unwind environments before block terminating instruction When we reach a block terminating instruction (e.g. Break, Throw), we cannot generate anymore instructions after it. This would not allow us to leave any lexical/variable environments. This uses the mechanism introduced in ba9c49 to unwind environments when we encounter these instructions.
2022-03-14 02:34:01 +00: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
bool needs_block_declaration_instantiation = false;
MUST(scope_node.for_each_lexically_scoped_declaration([&](Declaration const& declaration) {
if (declaration.is_function_declaration()) {
needs_block_declaration_instantiation = true;
return;
}
MUST(declaration.for_each_bound_identifier([&](auto const& id) {
if (!id.is_local())
needs_block_declaration_instantiation = true;
}));
}));
if (!needs_block_declaration_instantiation)
return false;
// FIXME: Generate the actual bytecode for block declaration instantiation
// and get rid of the BlockDeclarationInstantiation instruction.
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
start_boundary(BlockBoundaryType::LeaveLexicalEnvironment);
emit<Bytecode::Op::BlockDeclarationInstantiation>(scope_node);
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
return true;
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
}
void Generator::begin_variable_scope()
{
start_boundary(BlockBoundaryType::LeaveLexicalEnvironment);
LibJS/Bytecode: Simplify creating/leaving lexical environment Since we no longer need to create or leave var environments directly in bytecode, we can streamline the two instructions by making them always operate on the lexical environment.
2023-06-16 16:43:24 +02:00
emit<Bytecode::Op::CreateLexicalEnvironment>();
LibJS/Bytecode: Unwind environments before block terminating instruction When we reach a block terminating instruction (e.g. Break, Throw), we cannot generate anymore instructions after it. This would not allow us to leave any lexical/variable environments. This uses the mechanism introduced in ba9c49 to unwind environments when we encounter these instructions.
2022-03-14 02:34:01 +00:00
}
void Generator::end_variable_scope()
{
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
end_boundary(BlockBoundaryType::LeaveLexicalEnvironment);
LibJS/Bytecode: Unwind environments before block terminating instruction When we reach a block terminating instruction (e.g. Break, Throw), we cannot generate anymore instructions after it. This would not allow us to leave any lexical/variable environments. This uses the mechanism introduced in ba9c49 to unwind environments when we encounter these instructions.
2022-03-14 02:34:01 +00:00
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 (!m_current_basic_block->is_terminated()) {
LibJS/Bytecode: Simplify creating/leaving lexical environment Since we no longer need to create or leave var environments directly in bytecode, we can streamline the two instructions by making them always operate on the lexical environment.
2023-06-16 16:43:24 +02:00
emit<Bytecode::Op::LeaveLexicalEnvironment>();
LibJS/Bytecode: Unwind environments before block terminating instruction When we reach a block terminating instruction (e.g. Break, Throw), we cannot generate anymore instructions after it. This would not allow us to leave any lexical/variable environments. This uses the mechanism introduced in ba9c49 to unwind environments when we encounter these instructions.
2022-03-14 02:34:01 +00:00
}
}
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
void Generator::begin_continuable_scope(Label continue_target, Vector<DeprecatedFlyString> const& language_label_set)
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/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
m_continuable_scopes.append({ continue_target, language_label_set });
LibJS: Leave the unwind context on break/continue/return in bytecode Otherwise we'd keep the old unwind context, and end up never invoking the other handlers up the stack.
2022-03-13 11:51:02 +03:30
start_boundary(BlockBoundaryType::Continue);
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
}
void Generator::end_continuable_scope()
{
m_continuable_scopes.take_last();
LibJS: Leave the unwind context on break/continue/return in bytecode Otherwise we'd keep the old unwind context, and end up never invoking the other handlers up the stack.
2022-03-13 11:51:02 +03:30
end_boundary(BlockBoundaryType::Continue);
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/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: Implement bytecode generation for BreakStatement
2021-06-10 20:28:43 +08:00
Label Generator::nearest_breakable_scope() 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
return m_breakable_scopes.last().bytecode_target;
LibJS: Implement bytecode generation for BreakStatement
2021-06-10 20:28:43 +08: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
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
void Generator::begin_breakable_scope(Label breakable_target, Vector<DeprecatedFlyString> const& language_label_set)
LibJS: Implement bytecode generation for BreakStatement
2021-06-10 20:28:43 +08: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
m_breakable_scopes.append({ breakable_target, language_label_set });
LibJS: Leave the unwind context on break/continue/return in bytecode Otherwise we'd keep the old unwind context, and end up never invoking the other handlers up the stack.
2022-03-13 11:51:02 +03:30
start_boundary(BlockBoundaryType::Break);
LibJS: Implement bytecode generation for BreakStatement
2021-06-10 20:28:43 +08:00
}
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: Implement bytecode generation for BreakStatement
2021-06-10 20:28:43 +08:00
void Generator::end_breakable_scope()
{
m_breakable_scopes.take_last();
LibJS: Leave the unwind context on break/continue/return in bytecode Otherwise we'd keep the old unwind context, and end up never invoking the other handlers up the stack.
2022-03-13 11:51:02 +03:30
end_boundary(BlockBoundaryType::Break);
LibJS: Implement bytecode generation for BreakStatement
2021-06-10 20:28:43 +08:00
}
LibJS: Add BytecodeGenerator helpers for reference get/put This allows code sharing between all AST nodes that want to get and/or put through a reference.
2021-10-25 15:16:22 +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
CodeGenerationErrorOr<Generator::ReferenceOperands> Generator::emit_super_reference(MemberExpression const& expression)
LibJS/Bytecode: Extract code to generate a super reference to a helper This code is already repeated twice, and would be repeated a third time for the `delete` operator.
2023-07-06 17:02:06 -04:00
{
VERIFY(is<SuperExpression>(expression.object()));
// https://tc39.es/ecma262/#sec-super-keyword-runtime-semantics-evaluation
// 1. Let env be GetThisEnvironment().
// 2. Let actualThis be ? env.GetThisBinding().
LibJS/Bytecode: Always resolve `this` binding into dedicated register We already have a dedicated register slot for `this`, so instead of having ResolveThisBinding take a `dst` operand, just write the value directly into the `this` register every time.
2024-05-31 20:41:29 +02:00
auto actual_this = get_this();
LibJS/Bytecode: Extract code to generate a super reference to a helper This code is already repeated twice, and would be repeated a third time for the `delete` operator.
2023-07-06 17:02:06 -04: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_value;
LibJS/Bytecode: Extract code to generate a super reference to a helper This code is already repeated twice, and would be repeated a third time for the `delete` operator.
2023-07-06 17:02:06 -04:00
if (expression.is_computed()) {
// SuperProperty : super [ Expression ]
// 3. Let propertyNameReference be ? Evaluation of Expression.
// 4. Let propertyNameValue be ? GetValue(propertyNameReference).
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
computed_property_value = TRY(expression.property().generate_bytecode(*this)).value();
LibJS/Bytecode: Extract code to generate a super reference to a helper This code is already repeated twice, and would be repeated a third time for the `delete` operator.
2023-07-06 17:02:06 -04: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 base_value = 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
emit<Bytecode::Op::ResolveSuperBase>(base_value);
LibJS/Bytecode: Extract code to generate a super reference to a helper This code is already repeated twice, and would be repeated a third time for the `delete` operator.
2023-07-06 17:02:06 -04: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
return ReferenceOperands {
.base = base_value,
.referenced_name = computed_property_value,
.this_value = actual_this,
LibJS/Bytecode: Extract code to generate a super reference to a helper This code is already repeated twice, and would be repeated a third time for the `delete` operator.
2023-07-06 17:02:06 -04: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
CodeGenerationErrorOr<Generator::ReferenceOperands> Generator::emit_load_from_reference(JS::ASTNode const& node, Optional<ScopedOperand> preferred_dst)
LibJS: Add BytecodeGenerator helpers for reference get/put This allows code sharing between all AST nodes that want to get and/or put through a reference.
2021-10-25 15:16:22 +02:00
{
if (is<Identifier>(node)) {
auto& identifier = static_cast<Identifier const&>(node);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I 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 loaded_value = TRY(identifier.generate_bytecode(*this, preferred_dst)).value();
return ReferenceOperands {
.loaded_value = loaded_value,
};
LibJS: Add BytecodeGenerator helpers for reference get/put This allows code sharing between all AST nodes that want to get and/or put through a reference.
2021-10-25 15:16:22 +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<MemberExpression>(node)) {
return CodeGenerationError {
&node,
"Unimplemented/invalid node used as a reference"sv
};
}
auto& expression = static_cast<MemberExpression const&>(node);
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
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
// https://tc39.es/ecma262/#sec-super-keyword-runtime-semantics-evaluation
if (is<SuperExpression>(expression.object())) {
auto super_reference = TRY(emit_super_reference(expression));
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 = preferred_dst.has_value() ? preferred_dst.value() : 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 (super_reference.referenced_name.has_value()) {
// 5. Let propertyKey be ? ToPropertyKey(propertyNameValue).
// FIXME: This does ToPropertyKey out of order, which is observable by Symbol.toPrimitive!
emit<Bytecode::Op::GetByValueWithThis>(dst, *super_reference.base, *super_reference.referenced_name, *super_reference.this_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
} 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
// 3. Let propertyKey be StringValue of IdentifierName.
auto identifier_table_ref = intern_identifier(verify_cast<Identifier>(expression.property()).string());
emit_get_by_id_with_this(dst, *super_reference.base, identifier_table_ref, *super_reference.this_value);
LibJS: Add BytecodeGenerator helpers for reference get/put This allows code sharing between all AST nodes that want to get and/or put through a reference.
2021-10-25 15:16:22 +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
super_reference.loaded_value = dst;
return super_reference;
}
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
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I 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 base = TRY(expression.object().generate_bytecode(*this)).value();
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 = intern_identifier_for_expression(expression.object());
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I 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 (expression.is_computed()) {
auto property = TRY(expression.property().generate_bytecode(*this)).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 saved_property = allocate_register();
LibJS/Bytecode: Always evaluate LHS first in assignment expressions This fixes an issue where expressions like `a[i] = a[++i]` could evaluate `++i` before `a[i]`.
2024-03-05 09:48:13 +01:00
emit<Bytecode::Op::Mov>(saved_property, property);
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 = preferred_dst.has_value() ? preferred_dst.value() : allocate_register();
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
emit<Bytecode::Op::GetByValue>(dst, base, property, move(base_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
return ReferenceOperands {
.base = base,
LibJS/Bytecode: Always evaluate LHS first in assignment expressions This fixes an issue where expressions like `a[i] = a[++i]` could evaluate `++i` before `a[i]`.
2024-03-05 09:48:13 +01:00
.referenced_name = saved_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
.this_value = base,
.loaded_value = dst,
};
}
if (expression.property().is_identifier()) {
auto identifier_table_ref = intern_identifier(verify_cast<Identifier>(expression.property()).string());
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 = preferred_dst.has_value() ? preferred_dst.value() : allocate_register();
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
emit_get_by_id(dst, base, identifier_table_ref, move(base_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
return ReferenceOperands {
.base = base,
.referenced_identifier = identifier_table_ref,
.this_value = base,
.loaded_value = dst,
};
}
if (expression.property().is_private_identifier()) {
auto identifier_table_ref = intern_identifier(verify_cast<PrivateIdentifier>(expression.property()).string());
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 = preferred_dst.has_value() ? preferred_dst.value() : 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
emit<Bytecode::Op::GetPrivateById>(dst, base, identifier_table_ref);
return ReferenceOperands {
.base = base,
.referenced_private_identifier = identifier_table_ref,
.this_value = base,
.loaded_value = dst,
};
LibJS: Add BytecodeGenerator helpers for reference get/put This allows code sharing between all AST nodes that want to get and/or put through a reference.
2021-10-25 15:16:22 +02:00
}
LibJS: Don't crash when attempting to load from an invalid reference Previously, attempting to load a value from an invalid reference would cause a crash. We now return a CodeGenerationError rather than hitting an assertion. This is not a complete solution, as ideally we would want to return a ReferenceError, but this now matches the behavior we see when we attempt to store something to an invalid reference.
2024-01-31 22:27:11 +00:00
return CodeGenerationError {
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
&expression,
"Unimplemented non-computed member expression"sv
LibJS: Don't crash when attempting to load from an invalid reference Previously, attempting to load a value from an invalid reference would cause a crash. We now return a CodeGenerationError rather than hitting an assertion. This is not a complete solution, as ideally we would want to return a ReferenceError, but this now matches the behavior we see when we attempt to store something to an invalid reference.
2024-01-31 22:27:11 +00:00
};
LibJS: Add BytecodeGenerator helpers for reference get/put This allows code sharing between all AST nodes that want to get and/or put through a reference.
2021-10-25 15:16:22 +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
CodeGenerationErrorOr<void> Generator::emit_store_to_reference(JS::ASTNode const& node, ScopedOperand value)
LibJS: Add BytecodeGenerator helpers for reference get/put This allows code sharing between all AST nodes that want to get and/or put through a reference.
2021-10-25 15:16:22 +02:00
{
if (is<Identifier>(node)) {
auto& identifier = static_cast<Identifier const&>(node);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
emit_set_variable(identifier, value);
return {};
LibJS: Add BytecodeGenerator helpers for reference get/put This allows code sharing between all AST nodes that want to get and/or put through a reference.
2021-10-25 15:16:22 +02:00
}
if (is<MemberExpression>(node)) {
auto& expression = static_cast<MemberExpression const&>(node);
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
// https://tc39.es/ecma262/#sec-super-keyword-runtime-semantics-evaluation
if (is<SuperExpression>(expression.object())) {
LibJS/Bytecode: Extract code to generate a super reference to a helper This code is already repeated twice, and would be repeated a third time for the `delete` operator.
2023-07-06 17:02:06 -04:00
auto super_reference = TRY(emit_super_reference(expression));
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
// 4. Return the Reference Record { [[Base]]: baseValue, [[ReferencedName]]: propertyKey, [[Strict]]: strict, [[ThisValue]]: actualThis }.
LibJS/Bytecode: Extract code to generate a super reference to a helper This code is already repeated twice, and would be repeated a third time for the `delete` operator.
2023-07-06 17:02:06 -04:00
if (super_reference.referenced_name.has_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
// 5. Let propertyKey be ? ToPropertyKey(propertyNameValue).
// FIXME: This does ToPropertyKey out of order, which is observable by Symbol.toPrimitive!
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
emit<Bytecode::Op::PutByValueWithThis>(*super_reference.base, *super_reference.referenced_name, *super_reference.this_value, 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
} else {
// 3. Let propertyKey be StringValue of IdentifierName.
auto identifier_table_ref = intern_identifier(verify_cast<Identifier>(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
emit<Bytecode::Op::PutByIdWithThis>(*super_reference.base, *super_reference.this_value, identifier_table_ref, value, Bytecode::Op::PropertyKind::KeyValue, next_property_lookup_cache());
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: 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
} 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
auto object = TRY(expression.object().generate_bytecode(*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
if (expression.is_computed()) {
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I 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 property = TRY(expression.property().generate_bytecode(*this)).value();
emit<Bytecode::Op::PutByValue>(object, property, 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
} else if (expression.property().is_identifier()) {
auto identifier_table_ref = intern_identifier(verify_cast<Identifier>(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
emit<Bytecode::Op::PutById>(object, identifier_table_ref, value, Bytecode::Op::PropertyKind::KeyValue, next_property_lookup_cache());
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 if (expression.property().is_private_identifier()) {
auto identifier_table_ref = intern_identifier(verify_cast<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
emit<Bytecode::Op::PutPrivateById>(object, identifier_table_ref, 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
} else {
return CodeGenerationError {
&expression,
"Unimplemented non-computed member expression"sv
};
}
LibJS: Add BytecodeGenerator helpers for reference get/put This allows code sharing between all AST nodes that want to get and/or put through a reference.
2021-10-25 15:16:22 +02: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
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I 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 {};
LibJS: Add BytecodeGenerator helpers for reference get/put This allows code sharing between all AST nodes that want to get and/or put through a reference.
2021-10-25 15:16:22 +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: 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 CodeGenerationError {
&node,
"Unimplemented/invalid node used a reference"sv
};
LibJS: Add BytecodeGenerator helpers for reference get/put This allows code sharing between all AST nodes that want to get and/or put through a reference.
2021-10-25 15:16:22 +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
CodeGenerationErrorOr<void> Generator::emit_store_to_reference(ReferenceOperands const& reference, ScopedOperand 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
{
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I 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 (reference.referenced_private_identifier.has_value()) {
emit<Bytecode::Op::PutPrivateById>(*reference.base, *reference.referenced_private_identifier, value);
return {};
}
if (reference.referenced_identifier.has_value()) {
if (reference.base == reference.this_value)
emit<Bytecode::Op::PutById>(*reference.base, *reference.referenced_identifier, value, Bytecode::Op::PropertyKind::KeyValue, next_property_lookup_cache());
else
emit<Bytecode::Op::PutByIdWithThis>(*reference.base, *reference.this_value, *reference.referenced_identifier, value, Bytecode::Op::PropertyKind::KeyValue, next_property_lookup_cache());
return {};
}
if (reference.base == reference.this_value)
emit<Bytecode::Op::PutByValue>(*reference.base, *reference.referenced_name, 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/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
emit<Bytecode::Op::PutByValueWithThis>(*reference.base, *reference.referenced_name, *reference.this_value, value);
return {};
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
}
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
CodeGenerationErrorOr<Optional<ScopedOperand>> Generator::emit_delete_reference(JS::ASTNode const& node)
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 (is<Identifier>(node)) {
auto& identifier = static_cast<Identifier const&>(node);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I 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()) {
return add_constant(Value(false));
}
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 = 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
emit<Bytecode::Op::DeleteVariable>(dst, intern_identifier(identifier.string()));
return dst;
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 (is<MemberExpression>(node)) {
auto& expression = static_cast<MemberExpression const&>(node);
LibJS/Bytecode: Generate bytecode for deleting super properties
2023-07-06 17:10:40 -04:00
// https://tc39.es/ecma262/#sec-super-keyword-runtime-semantics-evaluation
if (is<SuperExpression>(expression.object())) {
auto super_reference = TRY(emit_super_reference(expression));
LibJS/Bytecode: Fix register being freed too early in `delete` codegen It wasn't actually possible for it to get reused incorrectly here, but let's fix the bug anyway.
2024-05-10 13:12:27 +02:00
auto dst = allocate_register();
LibJS/Bytecode: Generate bytecode for deleting super properties
2023-07-06 17:10:40 -04:00
if (super_reference.referenced_name.has_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
emit<Bytecode::Op::DeleteByValueWithThis>(dst, *super_reference.base, *super_reference.this_value, *super_reference.referenced_name);
LibJS/Bytecode: Generate bytecode for deleting super properties
2023-07-06 17:10:40 -04:00
} else {
auto identifier_table_ref = intern_identifier(verify_cast<Identifier>(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
emit<Bytecode::Op::DeleteByIdWithThis>(dst, *super_reference.base, *super_reference.this_value, identifier_table_ref);
LibJS/Bytecode: Generate bytecode for deleting super properties
2023-07-06 17:10:40 -04: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: Generate bytecode for deleting super properties
2023-07-06 17:10:40 -04: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 object = TRY(expression.object().generate_bytecode(*this)).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 dst = allocate_register();
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 (expression.is_computed()) {
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I 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 property = TRY(expression.property().generate_bytecode(*this)).value();
emit<Bytecode::Op::DeleteByValue>(dst, object, property);
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
} else if (expression.property().is_identifier()) {
auto identifier_table_ref = intern_identifier(verify_cast<Identifier>(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
emit<Bytecode::Op::DeleteById>(dst, object, identifier_table_ref);
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
} else {
// NOTE: Trying to delete a private field generates a SyntaxError in the parser.
return CodeGenerationError {
&expression,
"Unimplemented non-computed member expression"sv
};
}
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I 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/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
}
// Though this will have no deletion effect, we still have to evaluate the node as it can have side effects.
// For example: delete a(); delete ++c.b; etc.
// 13.5.1.2 Runtime Semantics: Evaluation, https://tc39.es/ecma262/#sec-delete-operator-runtime-semantics-evaluation
// 1. Let ref be the result of evaluating UnaryExpression.
// 2. ReturnIfAbrupt(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
(void)TRY(node.generate_bytecode(*this));
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
// 3. If ref is not a Reference Record, return true.
// NOTE: The rest of the steps are handled by Delete{Variable,ByValue,Id}.
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I 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 add_constant(Value(true));
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
}
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
void Generator::emit_set_variable(JS::Identifier const& identifier, ScopedOperand value, Bytecode::Op::BindingInitializationMode initialization_mode, Bytecode::Op::EnvironmentMode environment_mode)
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
{
if (identifier.is_local()) {
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
if (value.operand().is_local() && value.operand().index() == identifier.local_variable_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
// Moving a local to itself is a no-op.
return;
}
LibJS: Replace SetLocal instruction usage with Mov No need for separate instuction to set a local.
2024-05-14 04:40:47 +02:00
emit<Bytecode::Op::Mov>(local(identifier.local_variable_index()), value);
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/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 identifier_index = intern_identifier(identifier.string());
if (environment_mode == Bytecode::Op::EnvironmentMode::Lexical) {
if (initialization_mode == Bytecode::Op::BindingInitializationMode::Initialize) {
emit<Bytecode::Op::InitializeLexicalBinding>(identifier_index, value);
} else if (initialization_mode == Bytecode::Op::BindingInitializationMode::Set) {
emit<Bytecode::Op::SetLexicalBinding>(identifier_index, value);
}
} else if (environment_mode == Bytecode::Op::EnvironmentMode::Var) {
if (initialization_mode == Bytecode::Op::BindingInitializationMode::Initialize) {
emit<Bytecode::Op::InitializeVariableBinding>(identifier_index, value);
} else if (initialization_mode == Bytecode::Op::BindingInitializationMode::Set) {
emit<Bytecode::Op::SetVariableBinding>(identifier_index, value);
}
} else {
VERIFY_NOT_REACHED();
}
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: 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
static Optional<ByteString> expression_identifier(Expression const& expression)
{
if (expression.is_identifier()) {
auto const& identifier = static_cast<Identifier const&>(expression);
return identifier.string();
}
LibJS: Support numeric literal expressions in nullish object exceptions
2024-04-01 22:02:03 -04:00
if (expression.is_numeric_literal()) {
auto const& literal = static_cast<NumericLiteral const&>(expression);
return literal.value().to_string_without_side_effects().to_byte_string();
}
LibJS: Support string literal expressions in nullish object exceptions
2024-04-01 22:06:03 -04:00
if (expression.is_string_literal()) {
auto const& literal = static_cast<StringLiteral const&>(expression);
return ByteString::formatted("'{}'", literal.value());
}
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
if (expression.is_member_expression()) {
auto const& member_expression = static_cast<MemberExpression const&>(expression);
StringBuilder builder;
if (auto identifer = expression_identifier(member_expression.object()); identifer.has_value())
builder.append(*identifer);
if (auto identifer = expression_identifier(member_expression.property()); identifer.has_value()) {
LibJS: Support computed member expressions in nullish object exceptions
2024-04-01 22:00:29 -04:00
if (member_expression.is_computed())
builder.appendff("[{}]", *identifer);
else
builder.appendff(".{}", *identifer);
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
}
return builder.to_byte_string();
}
return {};
}
Optional<IdentifierTableIndex> Generator::intern_identifier_for_expression(Expression const& expression)
{
if (auto identifer = expression_identifier(expression); identifer.has_value())
return intern_identifier(identifer.release_value());
return {};
}
LibJS: Deduplicate scoped continue & break bytecode generation The only two differences between these two functions are the name of the block that is created and the specific jump/break handling per boundary.
2023-07-19 19:44:10 +12:00
void Generator::generate_scoped_jump(JumpType type)
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
{
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
TemporaryChange temp { m_current_unwind_context, m_current_unwind_context };
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
bool last_was_finally = false;
for (size_t i = m_boundaries.size(); i > 0; --i) {
auto boundary = m_boundaries[i - 1];
using enum BlockBoundaryType;
switch (boundary) {
case Break:
LibJS: Deduplicate scoped continue & break bytecode generation The only two differences between these two functions are the name of the block that is created and the specific jump/break handling per boundary.
2023-07-19 19:44:10 +12:00
if (type == JumpType::Break) {
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
emit<Op::Jump>(nearest_breakable_scope());
LibJS: Deduplicate scoped continue & break bytecode generation The only two differences between these two functions are the name of the block that is created and the specific jump/break handling per boundary.
2023-07-19 19:44:10 +12:00
return;
}
break;
case Continue:
if (type == JumpType::Continue) {
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
emit<Op::Jump>(nearest_continuable_scope());
LibJS: Deduplicate scoped continue & break bytecode generation The only two differences between these two functions are the name of the block that is created and the specific jump/break handling per boundary.
2023-07-19 19:44:10 +12:00
return;
}
break;
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
case Unwind:
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 (!last_was_finally) {
VERIFY(m_current_unwind_context && m_current_unwind_context->handler().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
emit<Bytecode::Op::LeaveUnwindContext>();
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
m_current_unwind_context = m_current_unwind_context->previous();
}
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
last_was_finally = false;
break;
case LeaveLexicalEnvironment:
LibJS/Bytecode: Simplify creating/leaving lexical environment Since we no longer need to create or leave var environments directly in bytecode, we can streamline the two instructions by making them always operate on the lexical environment.
2023-06-16 16:43:24 +02:00
emit<Bytecode::Op::LeaveLexicalEnvironment>();
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
break;
case 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
VERIFY(m_current_unwind_context->finalizer().has_value());
m_current_unwind_context = m_current_unwind_context->previous();
LibJS: Deduplicate scoped continue & break bytecode generation The only two differences between these two functions are the name of the block that is created and the specific jump/break handling per boundary.
2023-07-19 19:44:10 +12:00
auto jump_type_name = type == JumpType::Break ? "break"sv : "continue"sv;
LibJS: Migrate DeprecatedString to String This changes BasicBlock's constructor and create().
2023-10-26 23:57:51 -04:00
auto block_name = MUST(String::formatted("{}.{}", current_block().name(), jump_type_name));
auto& block = make_block(block_name);
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
emit<Op::ScheduleJump>(Label { block });
switch_to_basic_block(block);
last_was_finally = true;
break;
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
}
case LeaveFinally:
emit<Op::LeaveFinally>();
break;
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
}
}
VERIFY_NOT_REACHED();
}
LibJS: Deduplicate labelled continue & break bytecode generation Similar to the scoped continue and break, the only two differences between these functions is the scope that is scanned for a matching label, and the specific handling of a continue/break boundary.
2023-07-19 20:06:25 +12:00
void Generator::generate_labelled_jump(JumpType type, DeprecatedFlyString const& label)
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: 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
TemporaryChange temp { m_current_unwind_context, m_current_unwind_context };
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
size_t current_boundary = m_boundaries.size();
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
bool last_was_finally = false;
LibJS: Deduplicate labelled continue & break bytecode generation Similar to the scoped continue and break, the only two differences between these functions is the scope that is scanned for a matching label, and the specific handling of a continue/break boundary.
2023-07-19 20:06:25 +12:00
auto const& jumpable_scopes = type == JumpType::Continue ? m_continuable_scopes : m_breakable_scopes;
for (auto const& jumpable_scope : jumpable_scopes.in_reverse()) {
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
for (; current_boundary > 0; --current_boundary) {
auto boundary = m_boundaries[current_boundary - 1];
if (boundary == BlockBoundaryType::Unwind) {
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 (!last_was_finally) {
VERIFY(m_current_unwind_context && m_current_unwind_context->handler().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
emit<Bytecode::Op::LeaveUnwindContext>();
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
m_current_unwind_context = m_current_unwind_context->previous();
}
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
last_was_finally = false;
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 (boundary == BlockBoundaryType::LeaveLexicalEnvironment) {
LibJS/Bytecode: Simplify creating/leaving lexical environment Since we no longer need to create or leave var environments directly in bytecode, we can streamline the two instructions by making them always operate on the lexical environment.
2023-06-16 16:43:24 +02:00
emit<Bytecode::Op::LeaveLexicalEnvironment>();
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
} else if (boundary == 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
VERIFY(m_current_unwind_context->finalizer().has_value());
m_current_unwind_context = m_current_unwind_context->previous();
LibJS: Deduplicate labelled continue & break bytecode generation Similar to the scoped continue and break, the only two differences between these functions is the scope that is scanned for a matching label, and the specific handling of a continue/break boundary.
2023-07-19 20:06:25 +12:00
auto jump_type_name = type == JumpType::Break ? "break"sv : "continue"sv;
LibJS: Migrate DeprecatedString to String This changes BasicBlock's constructor and create().
2023-10-26 23:57:51 -04:00
auto block_name = MUST(String::formatted("{}.{}", current_block().name(), jump_type_name));
auto& block = make_block(block_name);
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
emit<Op::ScheduleJump>(Label { block });
switch_to_basic_block(block);
last_was_finally = true;
LibJS: Deduplicate labelled continue & break bytecode generation Similar to the scoped continue and break, the only two differences between these functions is the scope that is scanned for a matching label, and the specific handling of a continue/break boundary.
2023-07-19 20:06:25 +12:00
} else if ((type == JumpType::Continue && boundary == BlockBoundaryType::Continue) || (type == JumpType::Break && boundary == BlockBoundaryType::Break)) {
// Make sure we don't process this boundary twice if the current jumpable scope doesn't contain the target label.
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
--current_boundary;
break;
}
}
LibJS: Deduplicate labelled continue & break bytecode generation Similar to the scoped continue and break, the only two differences between these functions is the scope that is scanned for a matching label, and the specific handling of a continue/break boundary.
2023-07-19 20:06:25 +12:00
if (jumpable_scope.language_label_set.contains_slow(label)) {
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
emit<Op::Jump>(jumpable_scope.bytecode_target);
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
return;
}
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: Deduplicate labelled continue & break bytecode generation Similar to the scoped continue and break, the only two differences between these functions is the scope that is scanned for a matching label, and the specific handling of a continue/break boundary.
2023-07-19 20:06:25 +12:00
// We must have a jumpable scope available that contains the label, as this should be enforced by the parser.
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
VERIFY_NOT_REACHED();
}
LibJS: Deduplicate labelled continue & break bytecode generation Similar to the scoped continue and break, the only two differences between these functions is the scope that is scanned for a matching label, and the specific handling of a continue/break boundary.
2023-07-19 20:06:25 +12:00
void Generator::generate_break()
{
generate_scoped_jump(JumpType::Break);
}
void Generator::generate_break(DeprecatedFlyString const& break_label)
{
generate_labelled_jump(JumpType::Break, break_label);
}
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
void Generator::generate_continue()
{
LibJS: Deduplicate scoped continue & break bytecode generation The only two differences between these two functions are the name of the block that is created and the specific jump/break handling per boundary.
2023-07-19 19:44:10 +12:00
generate_scoped_jump(JumpType::Continue);
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
}
void Generator::generate_continue(DeprecatedFlyString const& continue_label)
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: Deduplicate labelled continue & break bytecode generation Similar to the scoped continue and break, the only two differences between these functions is the scope that is scanned for a matching label, and the specific handling of a continue/break boundary.
2023-07-19 20:06:25 +12:00
generate_labelled_jump(JumpType::Continue, continue_label);
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/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
void Generator::push_home_object(ScopedOperand 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/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 08:00:54 +01:00
m_home_objects.append(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
}
void Generator::pop_home_object()
{
m_home_objects.take_last();
}
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
void Generator::emit_new_function(ScopedOperand dst, FunctionExpression const& function_node, Optional<IdentifierTableIndex> lhs_name)
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/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I 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_home_objects.is_empty()) {
emit<Op::NewFunction>(dst, function_node, lhs_name);
} else {
emit<Op::NewFunction>(dst, function_node, lhs_name, m_home_objects.last());
}
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
CodeGenerationErrorOr<Optional<ScopedOperand>> Generator::emit_named_evaluation_if_anonymous_function(Expression const& expression, Optional<IdentifierTableIndex> lhs_name, Optional<ScopedOperand> 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
{
if (is<FunctionExpression>(expression)) {
auto const& function_expression = static_cast<FunctionExpression const&>(expression);
if (!function_expression.has_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
return TRY(function_expression.generate_bytecode_with_lhs_name(*this, move(lhs_name), preferred_dst)).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
}
}
if (is<ClassExpression>(expression)) {
auto const& class_expression = static_cast<ClassExpression const&>(expression);
if (!class_expression.has_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
return TRY(class_expression.generate_bytecode_with_lhs_name(*this, move(lhs_name), preferred_dst)).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/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I 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 expression.generate_bytecode(*this, preferred_dst);
}
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
void Generator::emit_get_by_id(ScopedOperand dst, ScopedOperand base, IdentifierTableIndex property_identifier, Optional<IdentifierTableIndex> base_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
{
LibJS/Bytecode: Add dedicated instruction for getting `length` property By doing this, we can remove all the special-case checks for `length` from the generic GetById and GetByIdWithThis code paths, making every other property lookup a bit faster. Small progressions on most benchmarks, and some larger progressions: - 12% on Octane/crypto.js - 6% on Kraken/ai-astar.js
2024-05-20 11:53:28 +02:00
if (m_identifier_table->get(property_identifier) == "length"sv) {
LibJS: Make GetById and GetByValue avoid get_identifier() in common case We now defer looking up the various identifiers by IdentifierTableIndex until the last moment. This allows us to avoid the retrieval in common cases like when a property access is cached. Knocks a ~12% item off the profile on https://ventrella.com/Clusters/
2024-07-09 11:37:06 +02:00
m_length_identifier = property_identifier;
LibJS/Bytecode: Add dedicated instruction for getting `length` property By doing this, we can remove all the special-case checks for `length` from the generic GetById and GetByIdWithThis code paths, making every other property lookup a bit faster. Small progressions on most benchmarks, and some larger progressions: - 12% on Octane/crypto.js - 6% on Kraken/ai-astar.js
2024-05-20 11:53:28 +02:00
emit<Op::GetLength>(dst, base, move(base_identifier), m_next_property_lookup_cache++);
return;
}
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
emit<Op::GetById>(dst, base, property_identifier, move(base_identifier), m_next_property_lookup_cache++);
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I 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
void Generator::emit_get_by_id_with_this(ScopedOperand dst, ScopedOperand base, IdentifierTableIndex id, ScopedOperand this_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: Add dedicated instruction for getting `length` property By doing this, we can remove all the special-case checks for `length` from the generic GetById and GetByIdWithThis code paths, making every other property lookup a bit faster. Small progressions on most benchmarks, and some larger progressions: - 12% on Octane/crypto.js - 6% on Kraken/ai-astar.js
2024-05-20 11:53:28 +02:00
if (m_identifier_table->get(id) == "length"sv) {
emit<Op::GetLengthWithThis>(dst, base, this_value, m_next_property_lookup_cache++);
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
emit<Op::GetByIdWithThis>(dst, base, id, this_value, m_next_property_lookup_cache++);
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/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
void Generator::emit_iterator_value(ScopedOperand dst, ScopedOperand result)
LibJS/Bytecode: Cache object own property accesses The instructions GetById and GetByIdWithThis now remember the last-seen Shape, and if we see the same object again, we reuse the property offset from last time without doing a new lookup. This allows us to use Object::get_direct(), bypassing the entire lookup machinery and saving lots of time. ~23% speed-up on Kraken/ai-astar.js :^)
2023-07-08 17:43:26 +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
emit_get_by_id(dst, result, intern_identifier("value"sv));
LibJS/Bytecode: Cache object own property accesses The instructions GetById and GetByIdWithThis now remember the last-seen Shape, and if we see the same object again, we reuse the property offset from last time without doing a new lookup. This allows us to use Object::get_direct(), bypassing the entire lookup machinery and saving lots of time. ~23% speed-up on Kraken/ai-astar.js :^)
2023-07-08 17:43: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
void Generator::emit_iterator_complete(ScopedOperand dst, ScopedOperand result)
LibJS/Bytecode: Cache object own property accesses The instructions GetById and GetByIdWithThis now remember the last-seen Shape, and if we see the same object again, we reuse the property offset from last time without doing a new lookup. This allows us to use Object::get_direct(), bypassing the entire lookup machinery and saving lots of time. ~23% speed-up on Kraken/ai-astar.js :^)
2023-07-08 17:43:26 +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
emit_get_by_id(dst, result, intern_identifier("done"sv));
LibJS/Bytecode: Cache object own property accesses The instructions GetById and GetByIdWithThis now remember the last-seen Shape, and if we see the same object again, we reuse the property offset from last time without doing a new lookup. This allows us to use Object::get_direct(), bypassing the entire lookup machinery and saving lots of time. ~23% speed-up on Kraken/ai-astar.js :^)
2023-07-08 17:43:26 +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
bool Generator::is_local_initialized(u32 local_index) const
LibJS: Remove dedicated iterator result instructions in favor of GetById When iterating over an iterable, we get back a JS object with the fields "value" and "done". Before this change, we've had two dedicated instructions for retrieving the two fields: IteratorResultValue and IteratorResultDone. These had no fast path whatsoever and just did a generic [[Get]] access to fetch the corresponding property values. By replacing the instructions with GetById("value") and GetById("done"), they instantly get caching and JIT fast paths for free, making iterating over iterables much faster. :^) 26% speed-up on this microbenchmark: function go(a) { for (const p of a) { } } const a = []; a.length = 1_000_000; go(a);
2023-12-07 16:12:12 +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 m_initialized_locals.find(local_index) != m_initialized_locals.end();
LibJS: Remove dedicated iterator result instructions in favor of GetById When iterating over an iterable, we get back a JS object with the fields "value" and "done". Before this change, we've had two dedicated instructions for retrieving the two fields: IteratorResultValue and IteratorResultDone. These had no fast path whatsoever and just did a generic [[Get]] access to fetch the corresponding property values. By replacing the instructions with GetById("value") and GetById("done"), they instantly get caching and JIT fast paths for free, making iterating over iterables much faster. :^) 26% speed-up on this microbenchmark: function go(a) { for (const p of a) { } } const a = []; a.length = 1_000_000; go(a);
2023-12-07 16:12:12 +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
void Generator::set_local_initialized(u32 local_index)
LibJS: Remove dedicated iterator result instructions in favor of GetById When iterating over an iterable, we get back a JS object with the fields "value" and "done". Before this change, we've had two dedicated instructions for retrieving the two fields: IteratorResultValue and IteratorResultDone. These had no fast path whatsoever and just did a generic [[Get]] access to fetch the corresponding property values. By replacing the instructions with GetById("value") and GetById("done"), they instantly get caching and JIT fast paths for free, making iterating over iterables much faster. :^) 26% speed-up on this microbenchmark: function go(a) { for (const p of a) { } } const a = []; a.length = 1_000_000; go(a);
2023-12-07 16:12:12 +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
m_initialized_locals.set(local_index);
LibJS: Remove dedicated iterator result instructions in favor of GetById When iterating over an iterable, we get back a JS object with the fields "value" and "done". Before this change, we've had two dedicated instructions for retrieving the two fields: IteratorResultValue and IteratorResultDone. These had no fast path whatsoever and just did a generic [[Get]] access to fetch the corresponding property values. By replacing the instructions with GetById("value") and GetById("done"), they instantly get caching and JIT fast paths for free, making iterating over iterables much faster. :^) 26% speed-up on this microbenchmark: function go(a) { for (const p of a) { } } const a = []; a.length = 1_000_000; go(a);
2023-12-07 16:12:12 +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
ScopedOperand Generator::get_this(Optional<ScopedOperand> preferred_dst)
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
{
LibJS/Bytecode: Always resolve `this` binding into dedicated register We already have a dedicated register slot for `this`, so instead of having ResolveThisBinding take a `dst` operand, just write the value directly into the `this` register every time.
2024-05-31 20:41:29 +02:00
if (m_current_basic_block->has_resolved_this())
return this_value();
if (m_root_basic_blocks[0]->has_resolved_this()) {
m_current_basic_block->set_has_resolved_this();
return this_value();
LibJS/Bytecode: Allow all basic blocks to use cached `this` from block 0 The first block in every executable will always execute first, so if it ends up doing a ResolveThisBinding, it's fine for all other blocks within the same executable to use the same `this` value.
2024-05-07 20:01:31 +02:00
}
LibJS/Bytecode: Don't generate ResolveThisBinding if not needed Functions that don't have a FunctionEnvironment will get their `this` value from the ExecutionContext. This patch stops generating ResolveThisBinding instructions at all for functions like that, and instead pre-populates the `this` register when entering a new bytecode executable.
2024-05-31 21:00:15 +02:00
// OPTIMIZATION: If we're compiling a function that doesn't allocate a FunctionEnvironment,
// it will always have the same `this` value as the outer function,
// and so the `this` value is already in the `this` register!
if (m_function && !m_function->allocates_function_environment())
return this_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 dst = preferred_dst.has_value() ? preferred_dst.value() : allocate_register();
LibJS/Bytecode: Always resolve `this` binding into dedicated register We already have a dedicated register slot for `this`, so instead of having ResolveThisBinding take a `dst` operand, just write the value directly into the `this` register every time.
2024-05-31 20:41:29 +02:00
emit<Bytecode::Op::ResolveThisBinding>();
m_current_basic_block->set_has_resolved_this();
return this_value();
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
}
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 Generator::accumulator()
{
return m_accumulator;
}
LibJS/Bytecode: Always resolve `this` binding into dedicated register We already have a dedicated register slot for `this`, so instead of having ResolveThisBinding take a `dst` operand, just write the value directly into the `this` register every time.
2024-05-31 20:41:29 +02:00
ScopedOperand Generator::this_value()
{
return m_this_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
bool Generator::fuse_compare_and_jump(ScopedOperand const& condition, Label true_target, Label false_target)
{
auto& last_instruction = *reinterpret_cast<Instruction const*>(m_current_basic_block->data() + m_current_basic_block->last_instruction_start_offset());
LibJS/Bytecode: Add fast paths for compare-and-jump with 2 numbers When comparing two numbers, we can avoid a lot of implicit type conversion nonsense and go straight to comparison, saving time in the most common case.
2024-05-13 09:23:53 +02:00
#define HANDLE_COMPARISON_OP(op_TitleCase, op_snake_case, numeric_operator) \
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
if (last_instruction.type() == Instruction::Type::op_TitleCase) { \
auto& comparison = static_cast<Op::op_TitleCase const&>(last_instruction); \
VERIFY(comparison.dst() == condition); \
auto lhs = comparison.lhs(); \
auto rhs = comparison.rhs(); \
m_current_basic_block->rewind(); \
emit<Op::Jump##op_TitleCase>(lhs, rhs, true_target, false_target); \
return true; \
}
JS_ENUMERATE_COMPARISON_OPS(HANDLE_COMPARISON_OP);
#undef HANDLE_COMPARISON_OP
return false;
}
void Generator::emit_jump_if(ScopedOperand const& condition, Label true_target, Label false_target)
{
LibJS/Bytecode: Turn `JumpIf true/false` into unconditional `Jump`
2024-05-09 15:16:22 +02:00
if (condition.operand().is_constant()) {
auto value = m_constants[condition.operand().index()];
if (value.is_boolean()) {
if (value.as_bool()) {
emit<Op::Jump>(true_target);
} else {
emit<Op::Jump>(false_target);
}
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
// NOTE: It's only safe to fuse compare-and-jump if the condition is a temporary with no other dependents.
if (condition.operand().is_register()
&& condition.ref_count() == 1
&& m_current_basic_block->size() > 0) {
if (fuse_compare_and_jump(condition, true_target, false_target))
return;
}
emit<Op::JumpIf>(condition, true_target, false_target);
}
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
ScopedOperand Generator::copy_if_needed_to_preserve_evaluation_order(ScopedOperand const& operand)
{
if (!operand.operand().is_local())
return operand;
auto new_register = allocate_register();
emit<Bytecode::Op::Mov>(new_register, operand);
return new_register;
}
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
ScopedOperand Generator::add_constant(Value value)
{
auto append_new_constant = [&] {
m_constants.append(value);
return ScopedOperand { *this, Operand(Operand::Type::Constant, m_constants.size() - 1) };
};
if (value.is_boolean()) {
if (value.as_bool()) {
if (!m_true_constant.has_value())
m_true_constant = append_new_constant();
return m_true_constant.value();
} else {
if (!m_false_constant.has_value())
m_false_constant = append_new_constant();
return m_false_constant.value();
}
}
if (value.is_undefined()) {
if (!m_undefined_constant.has_value())
m_undefined_constant = append_new_constant();
return m_undefined_constant.value();
}
if (value.is_null()) {
if (!m_null_constant.has_value())
m_null_constant = append_new_constant();
return m_null_constant.value();
}
if (value.is_empty()) {
if (!m_empty_constant.has_value())
m_empty_constant = append_new_constant();
return m_empty_constant.value();
}
if (value.is_int32()) {
auto as_int32 = value.as_i32();
return m_int32_constants.ensure(as_int32, [&] {
return append_new_constant();
});
}
return append_new_constant();
}
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
}
Reference in a new issue Copy permalink