AuroraMiddleware/v8
1
0
Fork 0
Code Issues 2 Pull Requests Releases Wiki Activity
6b67620ca9
v8/test/unittests/interpreter/interpreter-assembler-unittest.cc

554 lines
22 KiB
C++
Raw Normal View History

[interpreter] Add basic framework for bytecode handler code generation. Adds basic support for generation of interpreter bytecode handler code snippets. The InterpreterAssembler class exposes a set of low level, interpreter specific operations which can be used to build a Turbofan graph. The Interpreter class generates a bytecode handler snippet for each bytecode by assembling operations using an InterpreterAssembler. Currently only two simple bytecodes are supported: LoadLiteral0 and Return. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1239793002 Cr-Commit-Position: refs/heads/master@{#29814}
2015-07-23 14:21:26 +00:00
// Copyright 2015 the V8 project authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.
[Interpreter] Make InterpreterAssembler a subclass of CodeStubAssembler. Moves InterpreterAssembler out of the compiler directory and into the interpreter directory. Makes InterpreterAssembler as subclass of CodeStubAssembler. As part of this change, the special bytecode dispatch linkage type is removed and instead we use a InterfaceDispatchDescriptor and a normal CodeStub linkage type. Removes a bunch of duplicated logic in InterpreterAssembler and instead uses the CodeStubAssembler logic. Refactors Interpreter with these changes. Modifies CodeStubAssembler to add the extra operations required by the Interpreter (extra call types, raw memory access and some extra binary ops). Also adds the ability for subclasses to add extra prologue and epilogue operations around calls, which is required for the Interpreter. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1673333004 Cr-Commit-Position: refs/heads/master@{#33873}
2016-02-10 16:38:49 +00:00
#include "test/unittests/interpreter/interpreter-assembler-unittest.h"
[interpreter] Add basic framework for bytecode handler code generation. Adds basic support for generation of interpreter bytecode handler code snippets. The InterpreterAssembler class exposes a set of low level, interpreter specific operations which can be used to build a Turbofan graph. The Interpreter class generates a bytecode handler snippet for each bytecode by assembling operations using an InterpreterAssembler. Currently only two simple bytecodes are supported: LoadLiteral0 and Return. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1239793002 Cr-Commit-Position: refs/heads/master@{#29814}
2015-07-23 14:21:26 +00:00
[Interpreter] Add support for JS calls. Adds support for JS calls to the interpreter. In order to support calls from the interpreter, the PushArgsAndCall builtin is added which pushes a sequence of arguments onto the stack and calls builtin::Call. Adds the Call bytecode. MIPS port contributed by akos.palfi@imgtec.com in https://codereview.chromium.org/1334873002/ BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1323463005 Cr-Commit-Position: refs/heads/master@{#30710}
2015-09-14 10:05:18 +00:00
#include "src/code-factory.h"
[interpreter] Add basic framework for bytecode handler code generation. Adds basic support for generation of interpreter bytecode handler code snippets. The InterpreterAssembler class exposes a set of low level, interpreter specific operations which can be used to build a Turbofan graph. The Interpreter class generates a bytecode handler snippet for each bytecode by assembling operations using an InterpreterAssembler. Currently only two simple bytecodes are supported: LoadLiteral0 and Return. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1239793002 Cr-Commit-Position: refs/heads/master@{#29814}
2015-07-23 14:21:26 +00:00
#include "src/compiler/node.h"
[Interpreter] Add support for property load operations. Adds support for property load operations via Load/KeyedLoad ICs. Adds the following bytecodes: - LoadIC - KeyedLoadIC Also adds support to the interpreter assembler for loading the type feedback vector from the function on the stack, and calling ICs. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1309843007 Cr-Commit-Position: refs/heads/master@{#30543}
2015-09-02 13:03:06 +00:00
#include "src/interface-descriptors.h"
[turbofan] Remove obsolete unique.h includes in TurboFan. Now that it is no longer needed, this also removes the invalid inclusion of "object-inl.h" within the "unique.h" header file. Note that this change still leaves 2 violations of that rule in the code, checked with the "tools/check-inline-includes.sh" tool. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1321223002 Cr-Commit-Position: refs/heads/master@{#30503}
2015-09-01 10:30:40 +00:00
#include "src/isolate.h"
[iwyu] Pre-work for removing unallowed include macro-assembler.h -> assembler-inl.h BUG=v8:5294 Change-Id: If45f25aae8de526027b7851cb4efe0ccf4a7c4b1 Reviewed-on: https://chromium-review.googlesource.com/444226 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#43388}
2017-02-23 11:46:29 +00:00
#include "src/objects-inl.h"
[interpreter] Add basic framework for bytecode handler code generation. Adds basic support for generation of interpreter bytecode handler code snippets. The InterpreterAssembler class exposes a set of low level, interpreter specific operations which can be used to build a Turbofan graph. The Interpreter class generates a bytecode handler snippet for each bytecode by assembling operations using an InterpreterAssembler. Currently only two simple bytecodes are supported: LoadLiteral0 and Return. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1239793002 Cr-Commit-Position: refs/heads/master@{#29814}
2015-07-23 14:21:26 +00:00
#include "test/unittests/compiler/compiler-test-utils.h"
#include "test/unittests/compiler/node-test-utils.h"
[interpreter]: Changes to interpreter builtins for accumulator and register file registers. Makes the following modifications to the interpreter builtins and InterpreterAssembler: - Adds an accumulator register and initializes it to undefined() - Adds a register file pointer register and use it instead of FramePointer to access registers - Modifies builtin to support functions with 0 regiters in the register file - Modifies builtin to Call rather than TailCall to first bytecode handler. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1289863003 Cr-Commit-Position: refs/heads/master@{#30219}
2015-08-18 12:41:41 +00:00
using ::testing::_;
[presubmit] Enable and fix "build/namespaces" linter check. R=clemensh@chromium.org Change-Id: I42241713b7d14dd1cb321df0570566b0873c10a4 Reviewed-on: https://chromium-review.googlesource.com/647888 Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47793}
2017-09-04 10:47:27 +00:00
using v8::internal::compiler::Node;
namespace c = v8::internal::compiler;
[interpreter]: Changes to interpreter builtins for accumulator and register file registers. Makes the following modifications to the interpreter builtins and InterpreterAssembler: - Adds an accumulator register and initializes it to undefined() - Adds a register file pointer register and use it instead of FramePointer to access registers - Modifies builtin to support functions with 0 regiters in the register file - Modifies builtin to Call rather than TailCall to first bytecode handler. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1289863003 Cr-Commit-Position: refs/heads/master@{#30219}
2015-08-18 12:41:41 +00:00
[interpreter] Add basic framework for bytecode handler code generation. Adds basic support for generation of interpreter bytecode handler code snippets. The InterpreterAssembler class exposes a set of low level, interpreter specific operations which can be used to build a Turbofan graph. The Interpreter class generates a bytecode handler snippet for each bytecode by assembling operations using an InterpreterAssembler. Currently only two simple bytecodes are supported: LoadLiteral0 and Return. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1239793002 Cr-Commit-Position: refs/heads/master@{#29814}
2015-07-23 14:21:26 +00:00
namespace v8 {
namespace internal {
[Interpreter] Make InterpreterAssembler a subclass of CodeStubAssembler. Moves InterpreterAssembler out of the compiler directory and into the interpreter directory. Makes InterpreterAssembler as subclass of CodeStubAssembler. As part of this change, the special bytecode dispatch linkage type is removed and instead we use a InterfaceDispatchDescriptor and a normal CodeStub linkage type. Removes a bunch of duplicated logic in InterpreterAssembler and instead uses the CodeStubAssembler logic. Refactors Interpreter with these changes. Modifies CodeStubAssembler to add the extra operations required by the Interpreter (extra call types, raw memory access and some extra binary ops). Also adds the ability for subclasses to add extra prologue and epilogue operations around calls, which is required for the Interpreter. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1673333004 Cr-Commit-Position: refs/heads/master@{#33873}
2016-02-10 16:38:49 +00:00
namespace interpreter {
[jumbo] fix another set of unittest compilation errors This makes jumbo_file_merge_limit=50 work again. Bug: chromium:770684 Change-Id: I5db6566da876d71ea6ba50ff03b7652074b0a35f Reviewed-on: https://chromium-review.googlesource.com/725818 Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Mostyn Bramley-Moore <mostynb@vewd.com> Cr-Commit-Position: refs/heads/master@{#48728}
2017-10-18 17:01:45 +00:00
namespace interpreter_assembler_unittest {
[interpreter] Add basic framework for bytecode handler code generation. Adds basic support for generation of interpreter bytecode handler code snippets. The InterpreterAssembler class exposes a set of low level, interpreter specific operations which can be used to build a Turbofan graph. The Interpreter class generates a bytecode handler snippet for each bytecode by assembling operations using an InterpreterAssembler. Currently only two simple bytecodes are supported: LoadLiteral0 and Return. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1239793002 Cr-Commit-Position: refs/heads/master@{#29814}
2015-07-23 14:21:26 +00:00
Reland of [refactoring] Split CodeAssemblerState out of CodeAssembler This is in preparation for introducing more specialized CodeStubAssembler subclasses. The state object can be handed around, while the Assembler instances are temporary-scoped. BUG=v8:5628 Original review: https://codereview.chromium.org/2498073002/ Review-Url: https://codereview.chromium.org/2502293002 Cr-Commit-Position: refs/heads/master@{#41028}
2016-11-16 11:48:07 +00:00
InterpreterAssemblerTestState::InterpreterAssemblerTestState(
InterpreterAssemblerTest* test, Bytecode bytecode)
: compiler::CodeAssemblerState(
Make CallInterfaceDescriptor isolate-independent Currently each isolate stores its own array of {CallInterfaceDescriptorData}. This array has size 173, and each entry has 40 bytes. That's already 7kB per isolate. Additionally, each {CallInterfaceDescriptorData} allocates two heap-allocated arrays, which probably add up to more than the static size of the {CallInterfaceDescriptorData}. Note that all the {CallInterfaceDescriptorData} instances are initialized eagerly on isolate creation. Since {CallInterfaceDescriptor} is totally isolate independent itself, this CL refactors the current design to avoid a copy of them per isolate, and instead shares them process-wide. Still, we need to free the allocated heap arrays when the last isolate dies to avoid leaks. This can probably be refactored later by statically initializing more and avoiding the heap allocations all together. This refactoring will also allow us to use {CallInterfaceDescriptor}s from wasm background compilation threads, which are not bound to any isolate. R=mstarzinger@chromium.org, titzer@chromium.org Bug: v8:6600 Change-Id: If8625b89951eec8fa8986b49a5c166e874a72494 Reviewed-on: https://chromium-review.googlesource.com/1100879 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#53803}
2018-06-18 15:14:29 +00:00
test->isolate(), test->zone(), InterpreterDispatchDescriptor{},
Remove ComputeFlags, simply pass in Code::Kind instead of Code::Flags TBR: ofrobots@google.com, yangguo@chromium.org Bug: Change-Id: I6cb0704acabf9a7f2334de539a6600db8607baef Reviewed-on: https://chromium-review.googlesource.com/691720 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48237}
2017-09-29 14:59:24 +00:00
Code::BYTECODE_HANDLER, Bytecodes::ToString(bytecode),
Define return count and return types in CallInterfaceDescriptor. Bug: v8:7754, v8:6600 Change-Id: I4db943d4a4a02a14bba670f89661ea98c5e306dd Reviewed-on: https://chromium-review.googlesource.com/1107919 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#53907}
2018-06-21 08:47:48 +00:00
PoisoningMitigationLevel::kPoisonCriticalOnly) {}
Reland of [refactoring] Split CodeAssemblerState out of CodeAssembler This is in preparation for introducing more specialized CodeStubAssembler subclasses. The state object can be handed around, while the Assembler instances are temporary-scoped. BUG=v8:5628 Original review: https://codereview.chromium.org/2498073002/ Review-Url: https://codereview.chromium.org/2502293002 Cr-Commit-Position: refs/heads/master@{#41028}
2016-11-16 11:48:07 +00:00
[interpreter] Add basic framework for bytecode handler code generation. Adds basic support for generation of interpreter bytecode handler code snippets. The InterpreterAssembler class exposes a set of low level, interpreter specific operations which can be used to build a Turbofan graph. The Interpreter class generates a bytecode handler snippet for each bytecode by assembling operations using an InterpreterAssembler. Currently only two simple bytecodes are supported: LoadLiteral0 and Return. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1239793002 Cr-Commit-Position: refs/heads/master@{#29814}
2015-07-23 14:21:26 +00:00
const interpreter::Bytecode kBytecodes[] = {
[Interpreter] Add more bytecode definitions and add operand types. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1257543003 Cr-Commit-Position: refs/heads/master@{#29934}
2015-07-30 13:56:47 +00:00
#define DEFINE_BYTECODE(Name, ...) interpreter::Bytecode::k##Name,
[interpreter] Add basic framework for bytecode handler code generation. Adds basic support for generation of interpreter bytecode handler code snippets. The InterpreterAssembler class exposes a set of low level, interpreter specific operations which can be used to build a Turbofan graph. The Interpreter class generates a bytecode handler snippet for each bytecode by assembling operations using an InterpreterAssembler. Currently only two simple bytecodes are supported: LoadLiteral0 and Return. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1239793002 Cr-Commit-Position: refs/heads/master@{#29814}
2015-07-23 14:21:26 +00:00
BYTECODE_LIST(DEFINE_BYTECODE)
#undef DEFINE_BYTECODE
};
[interpreter][stubs] Fixing issues found by machine graph verifier. All issues in interpreter bytecode handlers are fixed. BUG= Review-Url: https://codereview.chromium.org/2552883012 Cr-Commit-Position: refs/heads/master@{#41649}
2016-12-12 14:52:30 +00:00
[interpreter] Add accumulator use description to bytecodes. Anotates bytecodes with a description of how each uses the accumulator. Validates annotations and uses of accumulator when generating bytecode handlers. Only prints the accumulator during tracing where used. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1852213002 Cr-Commit-Position: refs/heads/master@{#35281}
2016-04-06 07:57:35 +00:00
InterpreterAssemblerTest::InterpreterAssemblerForTest::
~InterpreterAssemblerForTest() {
// Tests don't necessarily read and write accumulator but
// InterpreterAssembler checks accumulator uses.
if (Bytecodes::ReadsAccumulator(bytecode())) {
GetAccumulator();
}
if (Bytecodes::WritesAccumulator(bytecode())) {
SetAccumulator(nullptr);
}
}
[interpreter] Add basic framework for bytecode handler code generation. Adds basic support for generation of interpreter bytecode handler code snippets. The InterpreterAssembler class exposes a set of low level, interpreter specific operations which can be used to build a Turbofan graph. The Interpreter class generates a bytecode handler snippet for each bytecode by assembling operations using an InterpreterAssembler. Currently only two simple bytecodes are supported: LoadLiteral0 and Return. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1239793002 Cr-Commit-Position: refs/heads/master@{#29814}
2015-07-23 14:21:26 +00:00
Matcher<Node*> InterpreterAssemblerTest::InterpreterAssemblerForTest::IsLoad(
[presubmit] Enable and fix "build/namespaces" linter check. R=clemensh@chromium.org Change-Id: I42241713b7d14dd1cb321df0570566b0873c10a4 Reviewed-on: https://chromium-review.googlesource.com/647888 Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47793}
2017-09-04 10:47:27 +00:00
const Matcher<c::LoadRepresentation>& rep_matcher,
[turbofan] unify interpreter and JIT speculation poisoning This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
2018-03-26 15:44:44 +00:00
const Matcher<Node*>& base_matcher, const Matcher<Node*>& index_matcher,
LoadSensitivity needs_poisoning) {
Replace array index masking with the poisoning approach. The idea is to mark all the branches and loads participating in array bounds checks, and let them contribute-to/use the poisoning register. In the code, the marks for array indexing operations now contain "Critical" in their name. By default (--untrusted-code-mitigations), we only instrument the "critical" operations with poisoning. With that in place, we also remove the array masking approach based on arithmetic. Since we do not propagate the poison through function calls, we introduce a node for poisoning an index that is passed through function call - the typical example is the bounds-checked index that is passed to the CharCodeAt builtin. Most of the code in this CL is threads through the three levels of protection (safe, critical, unsafe) for loads, branches and flags. Bug: chromium:798964 Change-Id: Ief68e2329528277b3ba9156115b2a6dcc540d52b Reviewed-on: https://chromium-review.googlesource.com/995413 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52883}
2018-04-30 12:13:54 +00:00
CHECK_NE(LoadSensitivity::kUnsafe, needs_poisoning);
CHECK_NE(PoisoningMitigationLevel::kPoisonAll, poisoning_level());
if (poisoning_level() == PoisoningMitigationLevel::kPoisonCriticalOnly &&
needs_poisoning == LoadSensitivity::kCritical) {
[turbofan] unify interpreter and JIT speculation poisoning This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
2018-03-26 15:44:44 +00:00
return ::i::compiler::IsPoisonedLoad(rep_matcher, base_matcher,
index_matcher, _, _);
}
Remove dummy control / effect edges from RMA Load / Store / Div nodes. Review URL: https://codereview.chromium.org/1510173004 Cr-Commit-Position: refs/heads/master@{#32762}
2015-12-10 17:07:15 +00:00
return ::i::compiler::IsLoad(rep_matcher, base_matcher, index_matcher, _, _);
[interpreter] Add basic framework for bytecode handler code generation. Adds basic support for generation of interpreter bytecode handler code snippets. The InterpreterAssembler class exposes a set of low level, interpreter specific operations which can be used to build a Turbofan graph. The Interpreter class generates a bytecode handler snippet for each bytecode by assembling operations using an InterpreterAssembler. Currently only two simple bytecodes are supported: LoadLiteral0 and Return. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1239793002 Cr-Commit-Position: refs/heads/master@{#29814}
2015-07-23 14:21:26 +00:00
}
Matcher<Node*> InterpreterAssemblerTest::InterpreterAssemblerForTest::IsStore(
[presubmit] Enable and fix "build/namespaces" linter check. R=clemensh@chromium.org Change-Id: I42241713b7d14dd1cb321df0570566b0873c10a4 Reviewed-on: https://chromium-review.googlesource.com/647888 Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47793}
2017-09-04 10:47:27 +00:00
const Matcher<c::StoreRepresentation>& rep_matcher,
[interpreter] Add basic framework for bytecode handler code generation. Adds basic support for generation of interpreter bytecode handler code snippets. The InterpreterAssembler class exposes a set of low level, interpreter specific operations which can be used to build a Turbofan graph. The Interpreter class generates a bytecode handler snippet for each bytecode by assembling operations using an InterpreterAssembler. Currently only two simple bytecodes are supported: LoadLiteral0 and Return. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1239793002 Cr-Commit-Position: refs/heads/master@{#29814}
2015-07-23 14:21:26 +00:00
const Matcher<Node*>& base_matcher, const Matcher<Node*>& index_matcher,
const Matcher<Node*>& value_matcher) {
return ::i::compiler::IsStore(rep_matcher, base_matcher, index_matcher,
Remove dummy control / effect edges from RMA Load / Store / Div nodes. Review URL: https://codereview.chromium.org/1510173004 Cr-Commit-Position: refs/heads/master@{#32762}
2015-12-10 17:07:15 +00:00
value_matcher, _, _);
[interpreter] Add basic framework for bytecode handler code generation. Adds basic support for generation of interpreter bytecode handler code snippets. The InterpreterAssembler class exposes a set of low level, interpreter specific operations which can be used to build a Turbofan graph. The Interpreter class generates a bytecode handler snippet for each bytecode by assembling operations using an InterpreterAssembler. Currently only two simple bytecodes are supported: LoadLiteral0 and Return. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1239793002 Cr-Commit-Position: refs/heads/master@{#29814}
2015-07-23 14:21:26 +00:00
}
[Intepreter] Add poisoning to bytecode operand reads. BUG=chromium:798964 Change-Id: I63c373ef3f27a3295fc79f5c82d78b5fd89a83da Reviewed-on: https://chromium-review.googlesource.com/888752 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#50925}
2018-01-29 12:16:32 +00:00
Matcher<Node*> InterpreterAssemblerTest::InterpreterAssemblerForTest::IsWordNot(
const Matcher<Node*>& value_matcher) {
return kPointerSize == 8 ? IsWord64Xor(value_matcher, c::IsInt64Constant(-1))
: IsWord32Xor(value_matcher, c::IsInt32Constant(-1));
}
[Interpreter] Add implementations for load immediate bytecodes. Adds implementations and tests for the following bytecodes: - LdaZero - LdaSmi8 - LdaUndefined - LdaNull - LdaTheHole - LdaTrue - LdaFalse - LdaLdar - LdaStar Also adds Smi tagging / untagging and OperandType typed BytecodeOperand operations to InterpreterAssembler. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1294793002 Cr-Commit-Position: refs/heads/master@{#30226}
2015-08-18 15:29:21 +00:00
Matcher<Node*>
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
InterpreterAssemblerTest::InterpreterAssemblerForTest::IsUnsignedByteOperand(
[turbofan] unify interpreter and JIT speculation poisoning This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
2018-03-26 15:44:44 +00:00
int offset, LoadSensitivity needs_poisoning) {
[csa] Add constant folding more universally to CodeAssembler operators Contributed by kanghua.yu@intel.com. Bug: None Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9 Reviewed-on: https://chromium-review.googlesource.com/604648 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Pan Deng <pan.deng@intel.com> Cr-Commit-Position: refs/heads/master@{#47968}
2017-09-11 13:44:42 +00:00
return IsLoad(
MachineType::Uint8(),
c::IsParameter(InterpreterDispatchDescriptor::kBytecodeArray),
c::IsIntPtrAdd(
c::IsParameter(InterpreterDispatchDescriptor::kBytecodeOffset),
[turbofan] unify interpreter and JIT speculation poisoning This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
2018-03-26 15:44:44 +00:00
c::IsIntPtrConstant(offset)),
needs_poisoning);
[interpreter] Add basic framework for bytecode handler code generation. Adds basic support for generation of interpreter bytecode handler code snippets. The InterpreterAssembler class exposes a set of low level, interpreter specific operations which can be used to build a Turbofan graph. The Interpreter class generates a bytecode handler snippet for each bytecode by assembling operations using an InterpreterAssembler. Currently only two simple bytecodes are supported: LoadLiteral0 and Return. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1239793002 Cr-Commit-Position: refs/heads/master@{#29814}
2015-07-23 14:21:26 +00:00
}
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
Matcher<Node*>
InterpreterAssemblerTest::InterpreterAssemblerForTest::IsSignedByteOperand(
[turbofan] unify interpreter and JIT speculation poisoning This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
2018-03-26 15:44:44 +00:00
int offset, LoadSensitivity needs_poisoning) {
[csa] Add constant folding more universally to CodeAssembler operators Contributed by kanghua.yu@intel.com. Bug: None Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9 Reviewed-on: https://chromium-review.googlesource.com/604648 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Pan Deng <pan.deng@intel.com> Cr-Commit-Position: refs/heads/master@{#47968}
2017-09-11 13:44:42 +00:00
return IsLoad(
MachineType::Int8(),
c::IsParameter(InterpreterDispatchDescriptor::kBytecodeArray),
c::IsIntPtrAdd(
c::IsParameter(InterpreterDispatchDescriptor::kBytecodeOffset),
[turbofan] unify interpreter and JIT speculation poisoning This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
2018-03-26 15:44:44 +00:00
c::IsIntPtrConstant(offset)),
needs_poisoning);
[interpreter] Add Interpreter{Entry,Exit}Trampoline builtins. Adds interpreter entry and exit trampoline builtins. Also implements the Return bytecode handler and fixes a few bugs in InterpreterAssembler highlighted by running on other architectures. MIPS and MIPS64 port contributed by Paul Lind (paul.lind@imgtec.com) BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1245133002 Cr-Commit-Position: refs/heads/master@{#29929}
2015-07-30 11:36:26 +00:00
}
[Interpreter] Add support for short (16 bit) operands. Adds support for short operands, starting with kIdx16. Introduces BytecodeTraits to enable compile time determination of various traits for a bytecode, such as size, operands, etc. Reworks BytecodeIterator, BytecodeArrayBuilder and Bytecodes::Decode to support 16 bit operands. Adds support to Interpreter to load 16 bit operands. Also fixes a bug with ToBoolean where it wouldn't get emitted at the start of a block, and added a test. BytecodeTraits template magic inspired by oth@chromium.org. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1370893002 Cr-Commit-Position: refs/heads/master@{#31058}
2015-10-01 17:22:58 +00:00
Matcher<Node*>
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
InterpreterAssemblerTest::InterpreterAssemblerForTest::IsUnsignedShortOperand(
[turbofan] unify interpreter and JIT speculation poisoning This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
2018-03-26 15:44:44 +00:00
int offset, LoadSensitivity needs_poisoning) {
[Interpreter] Add support for short (16 bit) operands. Adds support for short operands, starting with kIdx16. Introduces BytecodeTraits to enable compile time determination of various traits for a bytecode, such as size, operands, etc. Reworks BytecodeIterator, BytecodeArrayBuilder and Bytecodes::Decode to support 16 bit operands. Adds support to Interpreter to load 16 bit operands. Also fixes a bug with ToBoolean where it wouldn't get emitted at the start of a block, and added a test. BytecodeTraits template magic inspired by oth@chromium.org. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1370893002 Cr-Commit-Position: refs/heads/master@{#31058}
2015-10-01 17:22:58 +00:00
if (TargetSupportsUnalignedAccess()) {
return IsLoad(
[turbofan] Make MachineType a pair of enums. MachineType is now a class with two enum fields: - MachineRepresentation - MachineSemantic Both enums are usable on their own, and this change switches some places from using MachineType to use just MachineRepresentation. Most notably: - register allocator now uses just the representation. - Phi and Select nodes only refer to representations. Review URL: https://codereview.chromium.org/1513543003 Cr-Commit-Position: refs/heads/master@{#32738}
2015-12-10 09:03:30 +00:00
MachineType::Uint16(),
[presubmit] Enable and fix "build/namespaces" linter check. R=clemensh@chromium.org Change-Id: I42241713b7d14dd1cb321df0570566b0873c10a4 Reviewed-on: https://chromium-review.googlesource.com/647888 Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47793}
2017-09-04 10:47:27 +00:00
c::IsParameter(InterpreterDispatchDescriptor::kBytecodeArray),
[csa] Add constant folding more universally to CodeAssembler operators Contributed by kanghua.yu@intel.com. Bug: None Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9 Reviewed-on: https://chromium-review.googlesource.com/604648 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Pan Deng <pan.deng@intel.com> Cr-Commit-Position: refs/heads/master@{#47968}
2017-09-11 13:44:42 +00:00
c::IsIntPtrAdd(
[presubmit] Enable and fix "build/namespaces" linter check. R=clemensh@chromium.org Change-Id: I42241713b7d14dd1cb321df0570566b0873c10a4 Reviewed-on: https://chromium-review.googlesource.com/647888 Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47793}
2017-09-04 10:47:27 +00:00
c::IsParameter(InterpreterDispatchDescriptor::kBytecodeOffset),
[turbofan] unify interpreter and JIT speculation poisoning This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
2018-03-26 15:44:44 +00:00
c::IsIntPtrConstant(offset)),
needs_poisoning);
[Interpreter] Add support for short (16 bit) operands. Adds support for short operands, starting with kIdx16. Introduces BytecodeTraits to enable compile time determination of various traits for a bytecode, such as size, operands, etc. Reworks BytecodeIterator, BytecodeArrayBuilder and Bytecodes::Decode to support 16 bit operands. Adds support to Interpreter to load 16 bit operands. Also fixes a bug with ToBoolean where it wouldn't get emitted at the start of a block, and added a test. BytecodeTraits template magic inspired by oth@chromium.org. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1370893002 Cr-Commit-Position: refs/heads/master@{#31058}
2015-10-01 17:22:58 +00:00
} else {
#if V8_TARGET_LITTLE_ENDIAN
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
const int kStep = -1;
const int kMsbOffset = 1;
[Interpreter] Add support for short (16 bit) operands. Adds support for short operands, starting with kIdx16. Introduces BytecodeTraits to enable compile time determination of various traits for a bytecode, such as size, operands, etc. Reworks BytecodeIterator, BytecodeArrayBuilder and Bytecodes::Decode to support 16 bit operands. Adds support to Interpreter to load 16 bit operands. Also fixes a bug with ToBoolean where it wouldn't get emitted at the start of a block, and added a test. BytecodeTraits template magic inspired by oth@chromium.org. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1370893002 Cr-Commit-Position: refs/heads/master@{#31058}
2015-10-01 17:22:58 +00:00
#elif V8_TARGET_BIG_ENDIAN
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
const int kStep = 1;
const int kMsbOffset = 0;
[Interpreter] Add support for short (16 bit) operands. Adds support for short operands, starting with kIdx16. Introduces BytecodeTraits to enable compile time determination of various traits for a bytecode, such as size, operands, etc. Reworks BytecodeIterator, BytecodeArrayBuilder and Bytecodes::Decode to support 16 bit operands. Adds support to Interpreter to load 16 bit operands. Also fixes a bug with ToBoolean where it wouldn't get emitted at the start of a block, and added a test. BytecodeTraits template magic inspired by oth@chromium.org. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1370893002 Cr-Commit-Position: refs/heads/master@{#31058}
2015-10-01 17:22:58 +00:00
#else
#error "Unknown Architecture"
#endif
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
Matcher<Node*> bytes[2];
for (int i = 0; i < static_cast<int>(arraysize(bytes)); i++) {
bytes[i] = IsLoad(
MachineType::Uint8(),
[presubmit] Enable and fix "build/namespaces" linter check. R=clemensh@chromium.org Change-Id: I42241713b7d14dd1cb321df0570566b0873c10a4 Reviewed-on: https://chromium-review.googlesource.com/647888 Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47793}
2017-09-04 10:47:27 +00:00
c::IsParameter(InterpreterDispatchDescriptor::kBytecodeArray),
[csa] Add constant folding more universally to CodeAssembler operators Contributed by kanghua.yu@intel.com. Bug: None Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9 Reviewed-on: https://chromium-review.googlesource.com/604648 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Pan Deng <pan.deng@intel.com> Cr-Commit-Position: refs/heads/master@{#47968}
2017-09-11 13:44:42 +00:00
c::IsIntPtrAdd(
[presubmit] Enable and fix "build/namespaces" linter check. R=clemensh@chromium.org Change-Id: I42241713b7d14dd1cb321df0570566b0873c10a4 Reviewed-on: https://chromium-review.googlesource.com/647888 Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47793}
2017-09-04 10:47:27 +00:00
c::IsParameter(InterpreterDispatchDescriptor::kBytecodeOffset),
Fix interpreter-assembler-unittest to check poisoning on unaligned loads Check for poisoned loads in unaligned loads in interpreter-assembler-unittest node matcher. Change-Id: I5007ed1767edb035181c66028dda064b7792267f Reviewed-on: https://chromium-review.googlesource.com/1018902 Reviewed-by: Miran Karić <miran.karic@mips.com> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#52700}
2018-04-19 10:28:53 +00:00
c::IsIntPtrConstant(offset + kMsbOffset + kStep * i)),
needs_poisoning);
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
}
[csa] Add constant folding more universally to CodeAssembler operators Contributed by kanghua.yu@intel.com. Bug: None Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9 Reviewed-on: https://chromium-review.googlesource.com/604648 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Pan Deng <pan.deng@intel.com> Cr-Commit-Position: refs/heads/master@{#47968}
2017-09-11 13:44:42 +00:00
return c::IsWord32Or(
c::IsWord32Shl(bytes[0], c::IsInt32Constant(kBitsPerByte)), bytes[1]);
[Interpreter] Add support for short (16 bit) operands. Adds support for short operands, starting with kIdx16. Introduces BytecodeTraits to enable compile time determination of various traits for a bytecode, such as size, operands, etc. Reworks BytecodeIterator, BytecodeArrayBuilder and Bytecodes::Decode to support 16 bit operands. Adds support to Interpreter to load 16 bit operands. Also fixes a bug with ToBoolean where it wouldn't get emitted at the start of a block, and added a test. BytecodeTraits template magic inspired by oth@chromium.org. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1370893002 Cr-Commit-Position: refs/heads/master@{#31058}
2015-10-01 17:22:58 +00:00
}
}
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
Matcher<Node*>
InterpreterAssemblerTest::InterpreterAssemblerForTest::IsSignedShortOperand(
[turbofan] unify interpreter and JIT speculation poisoning This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
2018-03-26 15:44:44 +00:00
int offset, LoadSensitivity needs_poisoning) {
[Interpreter] Bytecodes for exchanging registers. New bytecodes for making registers with indicies wider than 1-byte accessible. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1555713002 Cr-Commit-Position: refs/heads/master@{#33091}
2016-01-04 17:38:17 +00:00
if (TargetSupportsUnalignedAccess()) {
[interpreter][stubs] Fixing issues found by machine graph verifier. All issues in interpreter bytecode handlers are fixed. BUG= Review-Url: https://codereview.chromium.org/2552883012 Cr-Commit-Position: refs/heads/master@{#41649}
2016-12-12 14:52:30 +00:00
return IsLoad(
[Interpreter] Bytecodes for exchanging registers. New bytecodes for making registers with indicies wider than 1-byte accessible. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1555713002 Cr-Commit-Position: refs/heads/master@{#33091}
2016-01-04 17:38:17 +00:00
MachineType::Int16(),
[presubmit] Enable and fix "build/namespaces" linter check. R=clemensh@chromium.org Change-Id: I42241713b7d14dd1cb321df0570566b0873c10a4 Reviewed-on: https://chromium-review.googlesource.com/647888 Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47793}
2017-09-04 10:47:27 +00:00
c::IsParameter(InterpreterDispatchDescriptor::kBytecodeArray),
[csa] Add constant folding more universally to CodeAssembler operators Contributed by kanghua.yu@intel.com. Bug: None Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9 Reviewed-on: https://chromium-review.googlesource.com/604648 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Pan Deng <pan.deng@intel.com> Cr-Commit-Position: refs/heads/master@{#47968}
2017-09-11 13:44:42 +00:00
c::IsIntPtrAdd(
[presubmit] Enable and fix "build/namespaces" linter check. R=clemensh@chromium.org Change-Id: I42241713b7d14dd1cb321df0570566b0873c10a4 Reviewed-on: https://chromium-review.googlesource.com/647888 Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47793}
2017-09-04 10:47:27 +00:00
c::IsParameter(InterpreterDispatchDescriptor::kBytecodeOffset),
[turbofan] unify interpreter and JIT speculation poisoning This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
2018-03-26 15:44:44 +00:00
c::IsIntPtrConstant(offset)),
needs_poisoning);
[Interpreter] Bytecodes for exchanging registers. New bytecodes for making registers with indicies wider than 1-byte accessible. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1555713002 Cr-Commit-Position: refs/heads/master@{#33091}
2016-01-04 17:38:17 +00:00
} else {
#if V8_TARGET_LITTLE_ENDIAN
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
const int kStep = -1;
const int kMsbOffset = 1;
[Interpreter] Bytecodes for exchanging registers. New bytecodes for making registers with indicies wider than 1-byte accessible. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1555713002 Cr-Commit-Position: refs/heads/master@{#33091}
2016-01-04 17:38:17 +00:00
#elif V8_TARGET_BIG_ENDIAN
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
const int kStep = 1;
const int kMsbOffset = 0;
[Interpreter] Bytecodes for exchanging registers. New bytecodes for making registers with indicies wider than 1-byte accessible. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1555713002 Cr-Commit-Position: refs/heads/master@{#33091}
2016-01-04 17:38:17 +00:00
#else
#error "Unknown Architecture"
#endif
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
Matcher<Node*> bytes[2];
for (int i = 0; i < static_cast<int>(arraysize(bytes)); i++) {
bytes[i] = IsLoad(
(i == 0) ? MachineType::Int8() : MachineType::Uint8(),
[presubmit] Enable and fix "build/namespaces" linter check. R=clemensh@chromium.org Change-Id: I42241713b7d14dd1cb321df0570566b0873c10a4 Reviewed-on: https://chromium-review.googlesource.com/647888 Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47793}
2017-09-04 10:47:27 +00:00
c::IsParameter(InterpreterDispatchDescriptor::kBytecodeArray),
[csa] Add constant folding more universally to CodeAssembler operators Contributed by kanghua.yu@intel.com. Bug: None Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9 Reviewed-on: https://chromium-review.googlesource.com/604648 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Pan Deng <pan.deng@intel.com> Cr-Commit-Position: refs/heads/master@{#47968}
2017-09-11 13:44:42 +00:00
c::IsIntPtrAdd(
[presubmit] Enable and fix "build/namespaces" linter check. R=clemensh@chromium.org Change-Id: I42241713b7d14dd1cb321df0570566b0873c10a4 Reviewed-on: https://chromium-review.googlesource.com/647888 Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47793}
2017-09-04 10:47:27 +00:00
c::IsParameter(InterpreterDispatchDescriptor::kBytecodeOffset),
[turbofan] unify interpreter and JIT speculation poisoning This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
2018-03-26 15:44:44 +00:00
c::IsIntPtrConstant(offset + kMsbOffset + kStep * i)),
needs_poisoning);
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
}
[csa] Add constant folding more universally to CodeAssembler operators Contributed by kanghua.yu@intel.com. Bug: None Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9 Reviewed-on: https://chromium-review.googlesource.com/604648 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Pan Deng <pan.deng@intel.com> Cr-Commit-Position: refs/heads/master@{#47968}
2017-09-11 13:44:42 +00:00
return c::IsWord32Or(
c::IsWord32Shl(bytes[0], c::IsInt32Constant(kBitsPerByte)), bytes[1]);
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
}
}
Matcher<Node*>
InterpreterAssemblerTest::InterpreterAssemblerForTest::IsUnsignedQuadOperand(
[turbofan] unify interpreter and JIT speculation poisoning This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
2018-03-26 15:44:44 +00:00
int offset, LoadSensitivity needs_poisoning) {
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
if (TargetSupportsUnalignedAccess()) {
return IsLoad(
MachineType::Uint32(),
[presubmit] Enable and fix "build/namespaces" linter check. R=clemensh@chromium.org Change-Id: I42241713b7d14dd1cb321df0570566b0873c10a4 Reviewed-on: https://chromium-review.googlesource.com/647888 Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47793}
2017-09-04 10:47:27 +00:00
c::IsParameter(InterpreterDispatchDescriptor::kBytecodeArray),
[csa] Add constant folding more universally to CodeAssembler operators Contributed by kanghua.yu@intel.com. Bug: None Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9 Reviewed-on: https://chromium-review.googlesource.com/604648 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Pan Deng <pan.deng@intel.com> Cr-Commit-Position: refs/heads/master@{#47968}
2017-09-11 13:44:42 +00:00
c::IsIntPtrAdd(
[presubmit] Enable and fix "build/namespaces" linter check. R=clemensh@chromium.org Change-Id: I42241713b7d14dd1cb321df0570566b0873c10a4 Reviewed-on: https://chromium-review.googlesource.com/647888 Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47793}
2017-09-04 10:47:27 +00:00
c::IsParameter(InterpreterDispatchDescriptor::kBytecodeOffset),
[turbofan] unify interpreter and JIT speculation poisoning This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
2018-03-26 15:44:44 +00:00
c::IsIntPtrConstant(offset)),
needs_poisoning);
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
} else {
#if V8_TARGET_LITTLE_ENDIAN
const int kStep = -1;
const int kMsbOffset = 3;
#elif V8_TARGET_BIG_ENDIAN
const int kStep = 1;
const int kMsbOffset = 0;
#else
#error "Unknown Architecture"
#endif
Matcher<Node*> bytes[4];
for (int i = 0; i < static_cast<int>(arraysize(bytes)); i++) {
bytes[i] = IsLoad(
MachineType::Uint8(),
[presubmit] Enable and fix "build/namespaces" linter check. R=clemensh@chromium.org Change-Id: I42241713b7d14dd1cb321df0570566b0873c10a4 Reviewed-on: https://chromium-review.googlesource.com/647888 Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47793}
2017-09-04 10:47:27 +00:00
c::IsParameter(InterpreterDispatchDescriptor::kBytecodeArray),
[csa] Add constant folding more universally to CodeAssembler operators Contributed by kanghua.yu@intel.com. Bug: None Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9 Reviewed-on: https://chromium-review.googlesource.com/604648 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Pan Deng <pan.deng@intel.com> Cr-Commit-Position: refs/heads/master@{#47968}
2017-09-11 13:44:42 +00:00
c::IsIntPtrAdd(
[presubmit] Enable and fix "build/namespaces" linter check. R=clemensh@chromium.org Change-Id: I42241713b7d14dd1cb321df0570566b0873c10a4 Reviewed-on: https://chromium-review.googlesource.com/647888 Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47793}
2017-09-04 10:47:27 +00:00
c::IsParameter(InterpreterDispatchDescriptor::kBytecodeOffset),
[turbofan] unify interpreter and JIT speculation poisoning This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
2018-03-26 15:44:44 +00:00
c::IsIntPtrConstant(offset + kMsbOffset + kStep * i)),
needs_poisoning);
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
}
[csa] Add constant folding more universally to CodeAssembler operators Contributed by kanghua.yu@intel.com. Bug: None Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9 Reviewed-on: https://chromium-review.googlesource.com/604648 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Pan Deng <pan.deng@intel.com> Cr-Commit-Position: refs/heads/master@{#47968}
2017-09-11 13:44:42 +00:00
return c::IsWord32Or(
c::IsWord32Shl(bytes[0], c::IsInt32Constant(3 * kBitsPerByte)),
c::IsWord32Or(
c::IsWord32Shl(bytes[1], c::IsInt32Constant(2 * kBitsPerByte)),
c::IsWord32Or(
c::IsWord32Shl(bytes[2], c::IsInt32Constant(1 * kBitsPerByte)),
bytes[3])));
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
}
}
Matcher<Node*>
InterpreterAssemblerTest::InterpreterAssemblerForTest::IsSignedQuadOperand(
[turbofan] unify interpreter and JIT speculation poisoning This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
2018-03-26 15:44:44 +00:00
int offset, LoadSensitivity needs_poisoning) {
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
if (TargetSupportsUnalignedAccess()) {
[interpreter][stubs] Fixing issues found by machine graph verifier. All issues in interpreter bytecode handlers are fixed. BUG= Review-Url: https://codereview.chromium.org/2552883012 Cr-Commit-Position: refs/heads/master@{#41649}
2016-12-12 14:52:30 +00:00
return IsLoad(
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
MachineType::Int32(),
[presubmit] Enable and fix "build/namespaces" linter check. R=clemensh@chromium.org Change-Id: I42241713b7d14dd1cb321df0570566b0873c10a4 Reviewed-on: https://chromium-review.googlesource.com/647888 Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47793}
2017-09-04 10:47:27 +00:00
c::IsParameter(InterpreterDispatchDescriptor::kBytecodeArray),
[csa] Add constant folding more universally to CodeAssembler operators Contributed by kanghua.yu@intel.com. Bug: None Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9 Reviewed-on: https://chromium-review.googlesource.com/604648 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Pan Deng <pan.deng@intel.com> Cr-Commit-Position: refs/heads/master@{#47968}
2017-09-11 13:44:42 +00:00
c::IsIntPtrAdd(
[presubmit] Enable and fix "build/namespaces" linter check. R=clemensh@chromium.org Change-Id: I42241713b7d14dd1cb321df0570566b0873c10a4 Reviewed-on: https://chromium-review.googlesource.com/647888 Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47793}
2017-09-04 10:47:27 +00:00
c::IsParameter(InterpreterDispatchDescriptor::kBytecodeOffset),
[turbofan] unify interpreter and JIT speculation poisoning This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
2018-03-26 15:44:44 +00:00
c::IsIntPtrConstant(offset)),
needs_poisoning);
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
} else {
#if V8_TARGET_LITTLE_ENDIAN
const int kStep = -1;
int kMsbOffset = 3;
#elif V8_TARGET_BIG_ENDIAN
const int kStep = 1;
int kMsbOffset = 0;
#else
#error "Unknown Architecture"
#endif
Matcher<Node*> bytes[4];
for (int i = 0; i < static_cast<int>(arraysize(bytes)); i++) {
bytes[i] = IsLoad(
(i == 0) ? MachineType::Int8() : MachineType::Uint8(),
[presubmit] Enable and fix "build/namespaces" linter check. R=clemensh@chromium.org Change-Id: I42241713b7d14dd1cb321df0570566b0873c10a4 Reviewed-on: https://chromium-review.googlesource.com/647888 Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47793}
2017-09-04 10:47:27 +00:00
c::IsParameter(InterpreterDispatchDescriptor::kBytecodeArray),
[csa] Add constant folding more universally to CodeAssembler operators Contributed by kanghua.yu@intel.com. Bug: None Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9 Reviewed-on: https://chromium-review.googlesource.com/604648 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Pan Deng <pan.deng@intel.com> Cr-Commit-Position: refs/heads/master@{#47968}
2017-09-11 13:44:42 +00:00
c::IsIntPtrAdd(
[presubmit] Enable and fix "build/namespaces" linter check. R=clemensh@chromium.org Change-Id: I42241713b7d14dd1cb321df0570566b0873c10a4 Reviewed-on: https://chromium-review.googlesource.com/647888 Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47793}
2017-09-04 10:47:27 +00:00
c::IsParameter(InterpreterDispatchDescriptor::kBytecodeOffset),
[turbofan] unify interpreter and JIT speculation poisoning This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
2018-03-26 15:44:44 +00:00
c::IsIntPtrConstant(offset + kMsbOffset + kStep * i)),
needs_poisoning);
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
}
[csa] Add constant folding more universally to CodeAssembler operators Contributed by kanghua.yu@intel.com. Bug: None Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9 Reviewed-on: https://chromium-review.googlesource.com/604648 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Pan Deng <pan.deng@intel.com> Cr-Commit-Position: refs/heads/master@{#47968}
2017-09-11 13:44:42 +00:00
return c::IsWord32Or(
c::IsWord32Shl(bytes[0], c::IsInt32Constant(3 * kBitsPerByte)),
c::IsWord32Or(
c::IsWord32Shl(bytes[1], c::IsInt32Constant(2 * kBitsPerByte)),
c::IsWord32Or(
c::IsWord32Shl(bytes[2], c::IsInt32Constant(1 * kBitsPerByte)),
bytes[3])));
[Interpreter] Bytecodes for exchanging registers. New bytecodes for making registers with indicies wider than 1-byte accessible. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1555713002 Cr-Commit-Position: refs/heads/master@{#33091}
2016-01-04 17:38:17 +00:00
}
}
[turbofan] unify interpreter and JIT speculation poisoning This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
2018-03-26 15:44:44 +00:00
Matcher<Node*>
InterpreterAssemblerTest::InterpreterAssemblerForTest::IsSignedOperand(
int offset, OperandSize operand_size, LoadSensitivity needs_poisoning) {
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
switch (operand_size) {
case OperandSize::kByte:
[turbofan] unify interpreter and JIT speculation poisoning This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
2018-03-26 15:44:44 +00:00
return IsSignedByteOperand(offset, needs_poisoning);
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
case OperandSize::kShort:
[turbofan] unify interpreter and JIT speculation poisoning This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
2018-03-26 15:44:44 +00:00
return IsSignedShortOperand(offset, needs_poisoning);
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
case OperandSize::kQuad:
[turbofan] unify interpreter and JIT speculation poisoning This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
2018-03-26 15:44:44 +00:00
return IsSignedQuadOperand(offset, needs_poisoning);
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
case OperandSize::kNone:
UNREACHABLE();
}
return nullptr;
}
[turbofan] unify interpreter and JIT speculation poisoning This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
2018-03-26 15:44:44 +00:00
Matcher<Node*>
InterpreterAssemblerTest::InterpreterAssemblerForTest::IsUnsignedOperand(
int offset, OperandSize operand_size, LoadSensitivity needs_poisoning) {
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
switch (operand_size) {
case OperandSize::kByte:
[turbofan] unify interpreter and JIT speculation poisoning This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
2018-03-26 15:44:44 +00:00
return IsUnsignedByteOperand(offset, needs_poisoning);
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
case OperandSize::kShort:
[turbofan] unify interpreter and JIT speculation poisoning This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
2018-03-26 15:44:44 +00:00
return IsUnsignedShortOperand(offset, needs_poisoning);
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
case OperandSize::kQuad:
[turbofan] unify interpreter and JIT speculation poisoning This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
2018-03-26 15:44:44 +00:00
return IsUnsignedQuadOperand(offset, needs_poisoning);
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
case OperandSize::kNone:
UNREACHABLE();
}
return nullptr;
}
[Intepreter] Add poisoning to bytecode operand reads. BUG=chromium:798964 Change-Id: I63c373ef3f27a3295fc79f5c82d78b5fd89a83da Reviewed-on: https://chromium-review.googlesource.com/888752 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#50925}
2018-01-29 12:16:32 +00:00
Matcher<compiler::Node*>
InterpreterAssemblerTest::InterpreterAssemblerForTest::IsLoadRegisterOperand(
int offset, OperandSize operand_size) {
[turbofan] unify interpreter and JIT speculation poisoning This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
2018-03-26 15:44:44 +00:00
Matcher<compiler::Node*> reg_operand = IsChangeInt32ToIntPtr(
IsSignedOperand(offset, operand_size, LoadSensitivity::kSafe));
return IsLoad(
MachineType::AnyTagged(), c::IsLoadParentFramePointer(),
c::IsWordShl(reg_operand, c::IsIntPtrConstant(kPointerSizeLog2)),
Replace array index masking with the poisoning approach. The idea is to mark all the branches and loads participating in array bounds checks, and let them contribute-to/use the poisoning register. In the code, the marks for array indexing operations now contain "Critical" in their name. By default (--untrusted-code-mitigations), we only instrument the "critical" operations with poisoning. With that in place, we also remove the array masking approach based on arithmetic. Since we do not propagate the poison through function calls, we introduce a node for poisoning an index that is passed through function call - the typical example is the bounds-checked index that is passed to the CharCodeAt builtin. Most of the code in this CL is threads through the three levels of protection (safe, critical, unsafe) for loads, branches and flags. Bug: chromium:798964 Change-Id: Ief68e2329528277b3ba9156115b2a6dcc540d52b Reviewed-on: https://chromium-review.googlesource.com/995413 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52883}
2018-04-30 12:13:54 +00:00
LoadSensitivity::kCritical);
[Intepreter] Add poisoning to bytecode operand reads. BUG=chromium:798964 Change-Id: I63c373ef3f27a3295fc79f5c82d78b5fd89a83da Reviewed-on: https://chromium-review.googlesource.com/888752 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#50925}
2018-01-29 12:16:32 +00:00
}
[Interpreter] Basic flow control. + Add bytecodes for conditional and unconditional jumps. + Add bytecodes for test/compare operations. + Expose jumps in bytecode-array-builder and add BytecodeLabel class for identifying jump targets. + Add support for if..then...else in the bytecode-generator. + Implement jump bytecodes in the interpreter. Test/compare operations dependent on runtime call for comparisons. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1343363002 Cr-Commit-Position: refs/heads/master@{#30918}
2015-09-24 15:20:47 +00:00
TARGET_TEST_F(InterpreterAssemblerTest, Jump) {
[Interpreter] Enable runtime profiler support for Ignition. Adds a profiling counter to each BytecodeArray object, and adds code to Jump and Return bytecode handlers to update this counter by the size of the jump or the distance from the return to the start of the function. This is more accurate than fullcodegen's approach since it takes forward jumps into account as well as back-edges. Modifies RuntimeProfiler to track ticks for interpreted frames. Currently we use the SharedFunctionInfo::profiler_ticks() instead of adding another to tick field to avoid adding another field to BytecodeArray since SharedFunctionInfo::profiler_ticks() is only used by Crankshaft otherwise so we shouldn't need both for BUG=v8:4689 LOG=N Review URL: https://codereview.chromium.org/1707693003 Cr-Commit-Position: refs/heads/master@{#34166}
2016-02-19 18:46:54 +00:00
// If debug code is enabled we emit extra code in Jump.
if (FLAG_debug_code) return;
[Interpreter] Basic flow control. + Add bytecodes for conditional and unconditional jumps. + Add bytecodes for test/compare operations. + Expose jumps in bytecode-array-builder and add BytecodeLabel class for identifying jump targets. + Add support for if..then...else in the bytecode-generator. + Implement jump bytecodes in the interpreter. Test/compare operations dependent on runtime call for comparisons. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1343363002 Cr-Commit-Position: refs/heads/master@{#30918}
2015-09-24 15:20:47 +00:00
int jump_offsets[] = {-9710, -77, 0, +3, +97109};
TRACED_FOREACH(int, jump_offset, jump_offsets) {
TRACED_FOREACH(interpreter::Bytecode, bytecode, kBytecodes) {
[interpreter] Inline Star on dispatch for some bytecodes For some bytecodes it is beneficial to always look for a Star bytecode when dispatching to the next and inline perform it without dispatching to the Star handler. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/2142273003 Cr-Commit-Position: refs/heads/master@{#37904}
2016-07-20 12:51:11 +00:00
if (!interpreter::Bytecodes::IsJump(bytecode)) return;
Reland of [refactoring] Split CodeAssemblerState out of CodeAssembler This is in preparation for introducing more specialized CodeStubAssembler subclasses. The state object can be handed around, while the Assembler instances are temporary-scoped. BUG=v8:5628 Original review: https://codereview.chromium.org/2498073002/ Review-Url: https://codereview.chromium.org/2502293002 Cr-Commit-Position: refs/heads/master@{#41028}
2016-11-16 11:48:07 +00:00
InterpreterAssemblerTestState state(this, bytecode);
InterpreterAssemblerForTest m(&state, bytecode);
[turbofan] Add the Verifier to the pipeline for code stubs. Removes some control edges added from the RawMachineAssembler to the end of the graph. Adds a parameter that tells the Verifier to ignore effect and control inputs. Review URL: https://codereview.chromium.org/1912853003 Cr-Commit-Position: refs/heads/master@{#35731}
2016-04-22 13:55:53 +00:00
Node* tail_call_node = m.Jump(m.IntPtrConstant(jump_offset));
[Interpreter] Basic flow control. + Add bytecodes for conditional and unconditional jumps. + Add bytecodes for test/compare operations. + Expose jumps in bytecode-array-builder and add BytecodeLabel class for identifying jump targets. + Add support for if..then...else in the bytecode-generator. + Implement jump bytecodes in the interpreter. Test/compare operations dependent on runtime call for comparisons. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1343363002 Cr-Commit-Position: refs/heads/master@{#30918}
2015-09-24 15:20:47 +00:00
[csa] Add constant folding more universally to CodeAssembler operators Contributed by kanghua.yu@intel.com. Bug: None Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9 Reviewed-on: https://chromium-review.googlesource.com/604648 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Pan Deng <pan.deng@intel.com> Cr-Commit-Position: refs/heads/master@{#47968}
2017-09-11 13:44:42 +00:00
Matcher<Node*> next_bytecode_offset_matcher = c::IsIntPtrAdd(
[presubmit] Enable and fix "build/namespaces" linter check. R=clemensh@chromium.org Change-Id: I42241713b7d14dd1cb321df0570566b0873c10a4 Reviewed-on: https://chromium-review.googlesource.com/647888 Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47793}
2017-09-04 10:47:27 +00:00
c::IsParameter(InterpreterDispatchDescriptor::kBytecodeOffset),
[csa] Add constant folding more universally to CodeAssembler operators Contributed by kanghua.yu@intel.com. Bug: None Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9 Reviewed-on: https://chromium-review.googlesource.com/604648 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Pan Deng <pan.deng@intel.com> Cr-Commit-Position: refs/heads/master@{#47968}
2017-09-11 13:44:42 +00:00
c::IsIntPtrConstant(jump_offset));
[Interpreter] Enable runtime profiler support for Ignition. Adds a profiling counter to each BytecodeArray object, and adds code to Jump and Return bytecode handlers to update this counter by the size of the jump or the distance from the return to the start of the function. This is more accurate than fullcodegen's approach since it takes forward jumps into account as well as back-edges. Modifies RuntimeProfiler to track ticks for interpreted frames. Currently we use the SharedFunctionInfo::profiler_ticks() instead of adding another to tick field to avoid adding another field to BytecodeArray since SharedFunctionInfo::profiler_ticks() is only used by Crankshaft otherwise so we shouldn't need both for BUG=v8:4689 LOG=N Review URL: https://codereview.chromium.org/1707693003 Cr-Commit-Position: refs/heads/master@{#34166}
2016-02-19 18:46:54 +00:00
Matcher<Node*> target_bytecode_matcher =
m.IsLoad(MachineType::Uint8(), _, next_bytecode_offset_matcher);
[csa] Add constant folding more universally to CodeAssembler operators Contributed by kanghua.yu@intel.com. Bug: None Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9 Reviewed-on: https://chromium-review.googlesource.com/604648 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Pan Deng <pan.deng@intel.com> Cr-Commit-Position: refs/heads/master@{#47968}
2017-09-11 13:44:42 +00:00
target_bytecode_matcher =
c::IsChangeUint32ToWord(target_bytecode_matcher);
[presubmit] Enable and fix "build/namespaces" linter check. R=clemensh@chromium.org Change-Id: I42241713b7d14dd1cb321df0570566b0873c10a4 Reviewed-on: https://chromium-review.googlesource.com/647888 Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47793}
2017-09-04 10:47:27 +00:00
Matcher<Node*> code_target_matcher = m.IsLoad(
MachineType::Pointer(),
c::IsParameter(InterpreterDispatchDescriptor::kDispatchTable),
[csa] Add constant folding more universally to CodeAssembler operators Contributed by kanghua.yu@intel.com. Bug: None Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9 Reviewed-on: https://chromium-review.googlesource.com/604648 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Pan Deng <pan.deng@intel.com> Cr-Commit-Position: refs/heads/master@{#47968}
2017-09-11 13:44:42 +00:00
c::IsWordShl(target_bytecode_matcher,
c::IsIntPtrConstant(kPointerSizeLog2)));
[Interpreter] Make InterpreterAssembler a subclass of CodeStubAssembler. Moves InterpreterAssembler out of the compiler directory and into the interpreter directory. Makes InterpreterAssembler as subclass of CodeStubAssembler. As part of this change, the special bytecode dispatch linkage type is removed and instead we use a InterfaceDispatchDescriptor and a normal CodeStub linkage type. Removes a bunch of duplicated logic in InterpreterAssembler and instead uses the CodeStubAssembler logic. Refactors Interpreter with these changes. Modifies CodeStubAssembler to add the extra operations required by the Interpreter (extra call types, raw memory access and some extra binary ops). Also adds the ability for subclasses to add extra prologue and epilogue operations around calls, which is required for the Interpreter. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1673333004 Cr-Commit-Position: refs/heads/master@{#33873}
2016-02-10 16:38:49 +00:00
[Interpreter] Basic flow control. + Add bytecodes for conditional and unconditional jumps. + Add bytecodes for test/compare operations. + Expose jumps in bytecode-array-builder and add BytecodeLabel class for identifying jump targets. + Add support for if..then...else in the bytecode-generator. + Implement jump bytecodes in the interpreter. Test/compare operations dependent on runtime call for comparisons. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1343363002 Cr-Commit-Position: refs/heads/master@{#30918}
2015-09-24 15:20:47 +00:00
EXPECT_THAT(
tail_call_node,
[csa] Add constant folding more universally to CodeAssembler operators Contributed by kanghua.yu@intel.com. Bug: None Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9 Reviewed-on: https://chromium-review.googlesource.com/604648 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Pan Deng <pan.deng@intel.com> Cr-Commit-Position: refs/heads/master@{#47968}
2017-09-11 13:44:42 +00:00
c::IsTailCall(
[presubmit] Enable and fix "build/namespaces" linter check. R=clemensh@chromium.org Change-Id: I42241713b7d14dd1cb321df0570566b0873c10a4 Reviewed-on: https://chromium-review.googlesource.com/647888 Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47793}
2017-09-04 10:47:27 +00:00
_, code_target_matcher,
c::IsParameter(InterpreterDispatchDescriptor::kAccumulator),
next_bytecode_offset_matcher, _,
c::IsParameter(InterpreterDispatchDescriptor::kDispatchTable), _,
_));
[Interpreter] Basic flow control. + Add bytecodes for conditional and unconditional jumps. + Add bytecodes for test/compare operations. + Expose jumps in bytecode-array-builder and add BytecodeLabel class for identifying jump targets. + Add support for if..then...else in the bytecode-generator. + Implement jump bytecodes in the interpreter. Test/compare operations dependent on runtime call for comparisons. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1343363002 Cr-Commit-Position: refs/heads/master@{#30918}
2015-09-24 15:20:47 +00:00
}
}
}
[Interpreter] Add more bytecode definitions and add operand types. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1257543003 Cr-Commit-Position: refs/heads/master@{#29934}
2015-07-30 13:56:47 +00:00
TARGET_TEST_F(InterpreterAssemblerTest, BytecodeOperand) {
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
static const OperandScale kOperandScales[] = {
OperandScale::kSingle, OperandScale::kDouble, OperandScale::kQuadruple};
[interpreter] Add basic framework for bytecode handler code generation. Adds basic support for generation of interpreter bytecode handler code snippets. The InterpreterAssembler class exposes a set of low level, interpreter specific operations which can be used to build a Turbofan graph. The Interpreter class generates a bytecode handler snippet for each bytecode by assembling operations using an InterpreterAssembler. Currently only two simple bytecodes are supported: LoadLiteral0 and Return. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1239793002 Cr-Commit-Position: refs/heads/master@{#29814}
2015-07-23 14:21:26 +00:00
TRACED_FOREACH(interpreter::Bytecode, bytecode, kBytecodes) {
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
TRACED_FOREACH(interpreter::OperandScale, operand_scale, kOperandScales) {
Reland of [refactoring] Split CodeAssemblerState out of CodeAssembler This is in preparation for introducing more specialized CodeStubAssembler subclasses. The state object can be handed around, while the Assembler instances are temporary-scoped. BUG=v8:5628 Original review: https://codereview.chromium.org/2498073002/ Review-Url: https://codereview.chromium.org/2502293002 Cr-Commit-Position: refs/heads/master@{#41028}
2016-11-16 11:48:07 +00:00
InterpreterAssemblerTestState state(this, bytecode);
InterpreterAssemblerForTest m(&state, bytecode, operand_scale);
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
int number_of_operands =
interpreter::Bytecodes::NumberOfOperands(bytecode);
for (int i = 0; i < number_of_operands; i++) {
int offset = interpreter::Bytecodes::GetOperandOffset(bytecode, i,
operand_scale);
OperandType operand_type =
interpreter::Bytecodes::GetOperandType(bytecode, i);
OperandSize operand_size =
Bytecodes::SizeOfOperand(operand_type, operand_scale);
switch (interpreter::Bytecodes::GetOperandType(bytecode, i)) {
case interpreter::OperandType::kRegCount:
EXPECT_THAT(m.BytecodeOperandCount(i),
[turbofan] unify interpreter and JIT speculation poisoning This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
2018-03-26 15:44:44 +00:00
m.IsUnsignedOperand(offset, operand_size,
Replace array index masking with the poisoning approach. The idea is to mark all the branches and loads participating in array bounds checks, and let them contribute-to/use the poisoning register. In the code, the marks for array indexing operations now contain "Critical" in their name. By default (--untrusted-code-mitigations), we only instrument the "critical" operations with poisoning. With that in place, we also remove the array masking approach based on arithmetic. Since we do not propagate the poison through function calls, we introduce a node for poisoning an index that is passed through function call - the typical example is the bounds-checked index that is passed to the CharCodeAt builtin. Most of the code in this CL is threads through the three levels of protection (safe, critical, unsafe) for loads, branches and flags. Bug: chromium:798964 Change-Id: Ief68e2329528277b3ba9156115b2a6dcc540d52b Reviewed-on: https://chromium-review.googlesource.com/995413 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52883}
2018-04-30 12:13:54 +00:00
LoadSensitivity::kCritical));
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
break;
case interpreter::OperandType::kFlag8:
EXPECT_THAT(m.BytecodeOperandFlag(i),
[turbofan] unify interpreter and JIT speculation poisoning This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
2018-03-26 15:44:44 +00:00
m.IsUnsignedOperand(offset, operand_size,
Replace array index masking with the poisoning approach. The idea is to mark all the branches and loads participating in array bounds checks, and let them contribute-to/use the poisoning register. In the code, the marks for array indexing operations now contain "Critical" in their name. By default (--untrusted-code-mitigations), we only instrument the "critical" operations with poisoning. With that in place, we also remove the array masking approach based on arithmetic. Since we do not propagate the poison through function calls, we introduce a node for poisoning an index that is passed through function call - the typical example is the bounds-checked index that is passed to the CharCodeAt builtin. Most of the code in this CL is threads through the three levels of protection (safe, critical, unsafe) for loads, branches and flags. Bug: chromium:798964 Change-Id: Ief68e2329528277b3ba9156115b2a6dcc540d52b Reviewed-on: https://chromium-review.googlesource.com/995413 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52883}
2018-04-30 12:13:54 +00:00
LoadSensitivity::kCritical));
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
break;
case interpreter::OperandType::kIdx:
Replace array index masking with the poisoning approach. The idea is to mark all the branches and loads participating in array bounds checks, and let them contribute-to/use the poisoning register. In the code, the marks for array indexing operations now contain "Critical" in their name. By default (--untrusted-code-mitigations), we only instrument the "critical" operations with poisoning. With that in place, we also remove the array masking approach based on arithmetic. Since we do not propagate the poison through function calls, we introduce a node for poisoning an index that is passed through function call - the typical example is the bounds-checked index that is passed to the CharCodeAt builtin. Most of the code in this CL is threads through the three levels of protection (safe, critical, unsafe) for loads, branches and flags. Bug: chromium:798964 Change-Id: Ief68e2329528277b3ba9156115b2a6dcc540d52b Reviewed-on: https://chromium-review.googlesource.com/995413 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52883}
2018-04-30 12:13:54 +00:00
EXPECT_THAT(m.BytecodeOperandIdx(i),
c::IsChangeUint32ToWord(m.IsUnsignedOperand(
offset, operand_size, LoadSensitivity::kCritical)));
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
break;
[interpreter] printing: output the native context index as string Bug: Change-Id: Iedd273d517e2ee2e548a5e9732689114800e6128 Reviewed-on: https://chromium-review.googlesource.com/649749 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#47822}
2017-09-05 11:23:26 +00:00
case interpreter::OperandType::kNativeContextIndex:
Replace array index masking with the poisoning approach. The idea is to mark all the branches and loads participating in array bounds checks, and let them contribute-to/use the poisoning register. In the code, the marks for array indexing operations now contain "Critical" in their name. By default (--untrusted-code-mitigations), we only instrument the "critical" operations with poisoning. With that in place, we also remove the array masking approach based on arithmetic. Since we do not propagate the poison through function calls, we introduce a node for poisoning an index that is passed through function call - the typical example is the bounds-checked index that is passed to the CharCodeAt builtin. Most of the code in this CL is threads through the three levels of protection (safe, critical, unsafe) for loads, branches and flags. Bug: chromium:798964 Change-Id: Ief68e2329528277b3ba9156115b2a6dcc540d52b Reviewed-on: https://chromium-review.googlesource.com/995413 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52883}
2018-04-30 12:13:54 +00:00
EXPECT_THAT(m.BytecodeOperandNativeContextIndex(i),
c::IsChangeUint32ToWord(m.IsUnsignedOperand(
offset, operand_size, LoadSensitivity::kCritical)));
[interpreter] printing: output the native context index as string Bug: Change-Id: Iedd273d517e2ee2e548a5e9732689114800e6128 Reviewed-on: https://chromium-review.googlesource.com/649749 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#47822}
2017-09-05 11:23:26 +00:00
break;
[Interpreter] Add an unsigned immediate operand type Review-Url: https://codereview.chromium.org/2336203002 Cr-Commit-Position: refs/heads/master@{#39388}
2016-09-13 14:48:39 +00:00
case interpreter::OperandType::kUImm:
EXPECT_THAT(m.BytecodeOperandUImm(i),
[turbofan] unify interpreter and JIT speculation poisoning This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
2018-03-26 15:44:44 +00:00
m.IsUnsignedOperand(offset, operand_size,
Replace array index masking with the poisoning approach. The idea is to mark all the branches and loads participating in array bounds checks, and let them contribute-to/use the poisoning register. In the code, the marks for array indexing operations now contain "Critical" in their name. By default (--untrusted-code-mitigations), we only instrument the "critical" operations with poisoning. With that in place, we also remove the array masking approach based on arithmetic. Since we do not propagate the poison through function calls, we introduce a node for poisoning an index that is passed through function call - the typical example is the bounds-checked index that is passed to the CharCodeAt builtin. Most of the code in this CL is threads through the three levels of protection (safe, critical, unsafe) for loads, branches and flags. Bug: chromium:798964 Change-Id: Ief68e2329528277b3ba9156115b2a6dcc540d52b Reviewed-on: https://chromium-review.googlesource.com/995413 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52883}
2018-04-30 12:13:54 +00:00
LoadSensitivity::kCritical));
[Interpreter] Add an unsigned immediate operand type Review-Url: https://codereview.chromium.org/2336203002 Cr-Commit-Position: refs/heads/master@{#39388}
2016-09-13 14:48:39 +00:00
break;
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
case interpreter::OperandType::kImm: {
EXPECT_THAT(m.BytecodeOperandImm(i),
[turbofan] unify interpreter and JIT speculation poisoning This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
2018-03-26 15:44:44 +00:00
m.IsSignedOperand(offset, operand_size,
Replace array index masking with the poisoning approach. The idea is to mark all the branches and loads participating in array bounds checks, and let them contribute-to/use the poisoning register. In the code, the marks for array indexing operations now contain "Critical" in their name. By default (--untrusted-code-mitigations), we only instrument the "critical" operations with poisoning. With that in place, we also remove the array masking approach based on arithmetic. Since we do not propagate the poison through function calls, we introduce a node for poisoning an index that is passed through function call - the typical example is the bounds-checked index that is passed to the CharCodeAt builtin. Most of the code in this CL is threads through the three levels of protection (safe, critical, unsafe) for loads, branches and flags. Bug: chromium:798964 Change-Id: Ief68e2329528277b3ba9156115b2a6dcc540d52b Reviewed-on: https://chromium-review.googlesource.com/995413 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52883}
2018-04-30 12:13:54 +00:00
LoadSensitivity::kCritical));
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
break;
}
case interpreter::OperandType::kRuntimeId:
EXPECT_THAT(m.BytecodeOperandRuntimeId(i),
[turbofan] unify interpreter and JIT speculation poisoning This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
2018-03-26 15:44:44 +00:00
m.IsUnsignedOperand(offset, operand_size,
Replace array index masking with the poisoning approach. The idea is to mark all the branches and loads participating in array bounds checks, and let them contribute-to/use the poisoning register. In the code, the marks for array indexing operations now contain "Critical" in their name. By default (--untrusted-code-mitigations), we only instrument the "critical" operations with poisoning. With that in place, we also remove the array masking approach based on arithmetic. Since we do not propagate the poison through function calls, we introduce a node for poisoning an index that is passed through function call - the typical example is the bounds-checked index that is passed to the CharCodeAt builtin. Most of the code in this CL is threads through the three levels of protection (safe, critical, unsafe) for loads, branches and flags. Bug: chromium:798964 Change-Id: Ief68e2329528277b3ba9156115b2a6dcc540d52b Reviewed-on: https://chromium-review.googlesource.com/995413 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52883}
2018-04-30 12:13:54 +00:00
LoadSensitivity::kCritical));
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
break;
Reland: [Interpreter] Map runtime id's to intrinsic id's in InvokeIntrinsic bytecode. Make intrinsic ids a contiguous set of ids so that the switch statement can build a table switch rather than doing a large if/else tree. BUG=v8:4822 LOG=N Committed: https://crrev.com/36abd28a8d9932eb55d7c2bf3ad5e7cfe3eb99ea Review-Url: https://codereview.chromium.org/2084623002 Cr-Original-Commit-Position: refs/heads/master@{#37135} Cr-Commit-Position: refs/heads/master@{#37145}
2016-06-21 14:37:16 +00:00
case interpreter::OperandType::kIntrinsicId:
EXPECT_THAT(m.BytecodeOperandIntrinsicId(i),
[turbofan] unify interpreter and JIT speculation poisoning This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
2018-03-26 15:44:44 +00:00
m.IsUnsignedOperand(offset, operand_size,
Replace array index masking with the poisoning approach. The idea is to mark all the branches and loads participating in array bounds checks, and let them contribute-to/use the poisoning register. In the code, the marks for array indexing operations now contain "Critical" in their name. By default (--untrusted-code-mitigations), we only instrument the "critical" operations with poisoning. With that in place, we also remove the array masking approach based on arithmetic. Since we do not propagate the poison through function calls, we introduce a node for poisoning an index that is passed through function call - the typical example is the bounds-checked index that is passed to the CharCodeAt builtin. Most of the code in this CL is threads through the three levels of protection (safe, critical, unsafe) for loads, branches and flags. Bug: chromium:798964 Change-Id: Ief68e2329528277b3ba9156115b2a6dcc540d52b Reviewed-on: https://chromium-review.googlesource.com/995413 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52883}
2018-04-30 12:13:54 +00:00
LoadSensitivity::kCritical));
Reland: [Interpreter] Map runtime id's to intrinsic id's in InvokeIntrinsic bytecode. Make intrinsic ids a contiguous set of ids so that the switch statement can build a table switch rather than doing a large if/else tree. BUG=v8:4822 LOG=N Committed: https://crrev.com/36abd28a8d9932eb55d7c2bf3ad5e7cfe3eb99ea Review-Url: https://codereview.chromium.org/2084623002 Cr-Original-Commit-Position: refs/heads/master@{#37135} Cr-Commit-Position: refs/heads/master@{#37145}
2016-06-21 14:37:16 +00:00
break;
[Intepreter] Add poisoning to bytecode operand reads. BUG=chromium:798964 Change-Id: I63c373ef3f27a3295fc79f5c82d78b5fd89a83da Reviewed-on: https://chromium-review.googlesource.com/888752 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#50925}
2018-01-29 12:16:32 +00:00
case interpreter::OperandType::kRegList:
case interpreter::OperandType::kReg:
case interpreter::OperandType::kRegPair:
case interpreter::OperandType::kRegOut:
case interpreter::OperandType::kRegOutList:
case interpreter::OperandType::kRegOutPair:
case interpreter::OperandType::kRegOutTriple:
EXPECT_THAT(m.LoadRegisterAtOperandIndex(i),
m.IsLoadRegisterOperand(offset, operand_size));
break;
[interpreter] Add support for scalable operands. This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:08:21 +00:00
case interpreter::OperandType::kNone:
UNREACHABLE();
break;
}
[interpreter]: Changes to interpreter builtins for accumulator and register file registers. Makes the following modifications to the interpreter builtins and InterpreterAssembler: - Adds an accumulator register and initializes it to undefined() - Adds a register file pointer register and use it instead of FramePointer to access registers - Modifies builtin to support functions with 0 regiters in the register file - Modifies builtin to Call rather than TailCall to first bytecode handler. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1289863003 Cr-Commit-Position: refs/heads/master@{#30219}
2015-08-18 12:41:41 +00:00
}
[interpreter] Add basic framework for bytecode handler code generation. Adds basic support for generation of interpreter bytecode handler code snippets. The InterpreterAssembler class exposes a set of low level, interpreter specific operations which can be used to build a Turbofan graph. The Interpreter class generates a bytecode handler snippet for each bytecode by assembling operations using an InterpreterAssembler. Currently only two simple bytecodes are supported: LoadLiteral0 and Return. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1239793002 Cr-Commit-Position: refs/heads/master@{#29814}
2015-07-23 14:21:26 +00:00
}
}
}
[Interpreter] No longer require context machine register in bytecode handlers The current context is stored as a stack slot on the interpreter frame and therefore we don't need to also maintain a machine register for the context. Removes this register from bytecode handlers. In the process modifies this frees up a register on ia32 to keep the dispatch table pointer in a register rather than on a stack slot on ia32. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1887493004 Cr-Commit-Position: refs/heads/master@{#35511}
2016-04-15 09:33:21 +00:00
TARGET_TEST_F(InterpreterAssemblerTest, GetContext) {
[Interpreter] Always store current context in the frames context slot. Change the interpreter to always store the current context in the frame's context slot instead of the function context. This makes it possible to restore the correct context during deopt. BUG=v8:4678,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1604923002 Cr-Commit-Position: refs/heads/master@{#33477}
2016-01-23 00:07:21 +00:00
TRACED_FOREACH(interpreter::Bytecode, bytecode, kBytecodes) {
Reland of [refactoring] Split CodeAssemblerState out of CodeAssembler This is in preparation for introducing more specialized CodeStubAssembler subclasses. The state object can be handed around, while the Assembler instances are temporary-scoped. BUG=v8:5628 Original review: https://codereview.chromium.org/2498073002/ Review-Url: https://codereview.chromium.org/2502293002 Cr-Commit-Position: refs/heads/master@{#41028}
2016-11-16 11:48:07 +00:00
InterpreterAssemblerTestState state(this, bytecode);
InterpreterAssemblerForTest m(&state, bytecode);
[Interpreter] No longer require context machine register in bytecode handlers The current context is stored as a stack slot on the interpreter frame and therefore we don't need to also maintain a machine register for the context. Removes this register from bytecode handlers. In the process modifies this frees up a register on ia32 to keep the dispatch table pointer in a register rather than on a stack slot on ia32. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1887493004 Cr-Commit-Position: refs/heads/master@{#35511}
2016-04-15 09:33:21 +00:00
EXPECT_THAT(
m.GetContext(),
[presubmit] Enable and fix "build/namespaces" linter check. R=clemensh@chromium.org Change-Id: I42241713b7d14dd1cb321df0570566b0873c10a4 Reviewed-on: https://chromium-review.googlesource.com/647888 Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47793}
2017-09-04 10:47:27 +00:00
m.IsLoad(MachineType::AnyTagged(), c::IsLoadParentFramePointer(),
[csa] Add constant folding more universally to CodeAssembler operators Contributed by kanghua.yu@intel.com. Bug: None Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9 Reviewed-on: https://chromium-review.googlesource.com/604648 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Pan Deng <pan.deng@intel.com> Cr-Commit-Position: refs/heads/master@{#47968}
2017-09-11 13:44:42 +00:00
c::IsIntPtrConstant(Register::current_context().ToOperand()
<< kPointerSizeLog2)));
[Interpreter] Always store current context in the frames context slot. Change the interpreter to always store the current context in the frame's context slot instead of the function context. This makes it possible to restore the correct context during deopt. BUG=v8:4678,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1604923002 Cr-Commit-Position: refs/heads/master@{#33477}
2016-01-23 00:07:21 +00:00
}
}
[Interpreter] Add support for loading literals from the constant pool. Adds support to the interpreter for loading literals from the constant pool. Adds the LoadConstant bytecode and makes use of it for loading large Smis and HeapObject literals. Also removes unused HandleVector from utils.h. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1321663003 Cr-Commit-Position: refs/heads/master@{#30450}
2015-08-28 15:40:52 +00:00
TARGET_TEST_F(InterpreterAssemblerTest, LoadConstantPoolEntry) {
TRACED_FOREACH(interpreter::Bytecode, bytecode, kBytecodes) {
Reland of [refactoring] Split CodeAssemblerState out of CodeAssembler This is in preparation for introducing more specialized CodeStubAssembler subclasses. The state object can be handed around, while the Assembler instances are temporary-scoped. BUG=v8:5628 Original review: https://codereview.chromium.org/2498073002/ Review-Url: https://codereview.chromium.org/2502293002 Cr-Commit-Position: refs/heads/master@{#41028}
2016-11-16 11:48:07 +00:00
InterpreterAssemblerTestState state(this, bytecode);
InterpreterAssemblerForTest m(&state, bytecode);
[interpreter][stubs] Fixing issues found by machine graph verifier. All issues in interpreter bytecode handlers are fixed. BUG= Review-Url: https://codereview.chromium.org/2552883012 Cr-Commit-Position: refs/heads/master@{#41649}
2016-12-12 14:52:30 +00:00
{
Node* index = m.IntPtrConstant(2);
Node* load_constant = m.LoadConstantPoolEntry(index);
[presubmit] Enable and fix "build/namespaces" linter check. R=clemensh@chromium.org Change-Id: I42241713b7d14dd1cb321df0570566b0873c10a4 Reviewed-on: https://chromium-review.googlesource.com/647888 Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47793}
2017-09-04 10:47:27 +00:00
Matcher<Node*> constant_pool_matcher = m.IsLoad(
MachineType::AnyTagged(),
c::IsParameter(InterpreterDispatchDescriptor::kBytecodeArray),
[csa] Add constant folding more universally to CodeAssembler operators Contributed by kanghua.yu@intel.com. Bug: None Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9 Reviewed-on: https://chromium-review.googlesource.com/604648 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Pan Deng <pan.deng@intel.com> Cr-Commit-Position: refs/heads/master@{#47968}
2017-09-11 13:44:42 +00:00
c::IsIntPtrConstant(BytecodeArray::kConstantPoolOffset -
kHeapObjectTag));
[turbofan] unify interpreter and JIT speculation poisoning This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
2018-03-26 15:44:44 +00:00
EXPECT_THAT(
load_constant,
m.IsLoad(MachineType::AnyTagged(), constant_pool_matcher,
c::IsIntPtrConstant(FixedArray::OffsetOfElementAt(2) -
kHeapObjectTag),
Replace array index masking with the poisoning approach. The idea is to mark all the branches and loads participating in array bounds checks, and let them contribute-to/use the poisoning register. In the code, the marks for array indexing operations now contain "Critical" in their name. By default (--untrusted-code-mitigations), we only instrument the "critical" operations with poisoning. With that in place, we also remove the array masking approach based on arithmetic. Since we do not propagate the poison through function calls, we introduce a node for poisoning an index that is passed through function call - the typical example is the bounds-checked index that is passed to the CharCodeAt builtin. Most of the code in this CL is threads through the three levels of protection (safe, critical, unsafe) for loads, branches and flags. Bug: chromium:798964 Change-Id: Ief68e2329528277b3ba9156115b2a6dcc540d52b Reviewed-on: https://chromium-review.googlesource.com/995413 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52883}
2018-04-30 12:13:54 +00:00
LoadSensitivity::kCritical));
[interpreter][stubs] Fixing issues found by machine graph verifier. All issues in interpreter bytecode handlers are fixed. BUG= Review-Url: https://codereview.chromium.org/2552883012 Cr-Commit-Position: refs/heads/master@{#41649}
2016-12-12 14:52:30 +00:00
}
{
Node* index = m.Parameter(2);
Node* load_constant = m.LoadConstantPoolEntry(index);
[presubmit] Enable and fix "build/namespaces" linter check. R=clemensh@chromium.org Change-Id: I42241713b7d14dd1cb321df0570566b0873c10a4 Reviewed-on: https://chromium-review.googlesource.com/647888 Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47793}
2017-09-04 10:47:27 +00:00
Matcher<Node*> constant_pool_matcher = m.IsLoad(
MachineType::AnyTagged(),
c::IsParameter(InterpreterDispatchDescriptor::kBytecodeArray),
[csa] Add constant folding more universally to CodeAssembler operators Contributed by kanghua.yu@intel.com. Bug: None Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9 Reviewed-on: https://chromium-review.googlesource.com/604648 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Pan Deng <pan.deng@intel.com> Cr-Commit-Position: refs/heads/master@{#47968}
2017-09-11 13:44:42 +00:00
c::IsIntPtrConstant(BytecodeArray::kConstantPoolOffset -
kHeapObjectTag));
[interpreter][stubs] Fixing issues found by machine graph verifier. All issues in interpreter bytecode handlers are fixed. BUG= Review-Url: https://codereview.chromium.org/2552883012 Cr-Commit-Position: refs/heads/master@{#41649}
2016-12-12 14:52:30 +00:00
EXPECT_THAT(
load_constant,
[turbofan] unify interpreter and JIT speculation poisoning This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
2018-03-26 15:44:44 +00:00
m.IsLoad(
[interpreter][stubs] Fixing issues found by machine graph verifier. All issues in interpreter bytecode handlers are fixed. BUG= Review-Url: https://codereview.chromium.org/2552883012 Cr-Commit-Position: refs/heads/master@{#41649}
2016-12-12 14:52:30 +00:00
MachineType::AnyTagged(), constant_pool_matcher,
[csa] Add constant folding more universally to CodeAssembler operators Contributed by kanghua.yu@intel.com. Bug: None Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9 Reviewed-on: https://chromium-review.googlesource.com/604648 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Pan Deng <pan.deng@intel.com> Cr-Commit-Position: refs/heads/master@{#47968}
2017-09-11 13:44:42 +00:00
c::IsIntPtrAdd(
c::IsIntPtrConstant(FixedArray::kHeaderSize - kHeapObjectTag),
[turbofan] unify interpreter and JIT speculation poisoning This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
2018-03-26 15:44:44 +00:00
c::IsWordShl(index, c::IsIntPtrConstant(kPointerSizeLog2))),
Replace array index masking with the poisoning approach. The idea is to mark all the branches and loads participating in array bounds checks, and let them contribute-to/use the poisoning register. In the code, the marks for array indexing operations now contain "Critical" in their name. By default (--untrusted-code-mitigations), we only instrument the "critical" operations with poisoning. With that in place, we also remove the array masking approach based on arithmetic. Since we do not propagate the poison through function calls, we introduce a node for poisoning an index that is passed through function call - the typical example is the bounds-checked index that is passed to the CharCodeAt builtin. Most of the code in this CL is threads through the three levels of protection (safe, critical, unsafe) for loads, branches and flags. Bug: chromium:798964 Change-Id: Ief68e2329528277b3ba9156115b2a6dcc540d52b Reviewed-on: https://chromium-review.googlesource.com/995413 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52883}
2018-04-30 12:13:54 +00:00
LoadSensitivity::kCritical));
[interpreter][stubs] Fixing issues found by machine graph verifier. All issues in interpreter bytecode handlers are fixed. BUG= Review-Url: https://codereview.chromium.org/2552883012 Cr-Commit-Position: refs/heads/master@{#41649}
2016-12-12 14:52:30 +00:00
}
[Interpreter] Add support for for..in. For..in introduces 3 new bytecodes ForInPrepare, ForInNext, and ForInDone to start a for..in loop, get the next element, and check if the loop is done. For..in builds upon new LoopBuilder constructs for conditionally breaking and continuing during iteration: BreakIf{Null|Undefined} and ContinueIf{Null|Undefined}. New conditional jump bytecodes support this succinctly: JumpIfNull and JumpIfUndefined. Add missing check to BytecodeLabel that could allow multiple forward referencess to the same label which is not supported. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1422033002 Cr-Commit-Position: refs/heads/master@{#31651}
2015-10-29 12:06:00 +00:00
}
}
TARGET_TEST_F(InterpreterAssemblerTest, LoadObjectField) {
TRACED_FOREACH(interpreter::Bytecode, bytecode, kBytecodes) {
Reland of [refactoring] Split CodeAssemblerState out of CodeAssembler This is in preparation for introducing more specialized CodeStubAssembler subclasses. The state object can be handed around, while the Assembler instances are temporary-scoped. BUG=v8:5628 Original review: https://codereview.chromium.org/2498073002/ Review-Url: https://codereview.chromium.org/2502293002 Cr-Commit-Position: refs/heads/master@{#41028}
2016-11-16 11:48:07 +00:00
InterpreterAssemblerTestState state(this, bytecode);
InterpreterAssemblerForTest m(&state, bytecode);
Normalize casing of hexadecimal digits This patch normalizes the casing of hexadecimal digits in escape sequences of the form `\xNN` and integer literals of the form `0xNNNN`. Previously, the V8 code base used an inconsistent mixture of uppercase and lowercase. Google’s C++ style guide uses uppercase in its examples: https://google.github.io/styleguide/cppguide.html#Non-ASCII_Characters Moreover, uppercase letters more clearly stand out from the lowercase `x` (or `u`) characters at the start, as well as lowercase letters elsewhere in strings. BUG=v8:7109 TBR=marja@chromium.org,titzer@chromium.org,mtrofin@chromium.org,mstarzinger@chromium.org,rossberg@chromium.org,yangguo@chromium.org,mlippautz@chromium.org NOPRESUBMIT=true Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I790e21c25d96ad5d95c8229724eb45d2aa9e22d6 Reviewed-on: https://chromium-review.googlesource.com/804294 Commit-Queue: Mathias Bynens <mathias@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#49810}
2017-12-02 00:30:37 +00:00
Node* object = m.IntPtrConstant(0xDEADBEEF);
[Interpreter] Add support for for..in. For..in introduces 3 new bytecodes ForInPrepare, ForInNext, and ForInDone to start a for..in loop, get the next element, and check if the loop is done. For..in builds upon new LoopBuilder constructs for conditionally breaking and continuing during iteration: BreakIf{Null|Undefined} and ContinueIf{Null|Undefined}. New conditional jump bytecodes support this succinctly: JumpIfNull and JumpIfUndefined. Add missing check to BytecodeLabel that could allow multiple forward referencess to the same label which is not supported. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1422033002 Cr-Commit-Position: refs/heads/master@{#31651}
2015-10-29 12:06:00 +00:00
int offset = 16;
Node* load_field = m.LoadObjectField(object, offset);
EXPECT_THAT(load_field,
[turbofan] Make MachineType a pair of enums. MachineType is now a class with two enum fields: - MachineRepresentation - MachineSemantic Both enums are usable on their own, and this change switches some places from using MachineType to use just MachineRepresentation. Most notably: - register allocator now uses just the representation. - Phi and Select nodes only refer to representations. Review URL: https://codereview.chromium.org/1513543003 Cr-Commit-Position: refs/heads/master@{#32738}
2015-12-10 09:03:30 +00:00
m.IsLoad(MachineType::AnyTagged(), object,
[csa] Add constant folding more universally to CodeAssembler operators Contributed by kanghua.yu@intel.com. Bug: None Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9 Reviewed-on: https://chromium-review.googlesource.com/604648 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Pan Deng <pan.deng@intel.com> Cr-Commit-Position: refs/heads/master@{#47968}
2017-09-11 13:44:42 +00:00
c::IsIntPtrConstant(offset - kHeapObjectTag)));
[Interpreter] Add support for for..in. For..in introduces 3 new bytecodes ForInPrepare, ForInNext, and ForInDone to start a for..in loop, get the next element, and check if the loop is done. For..in builds upon new LoopBuilder constructs for conditionally breaking and continuing during iteration: BreakIf{Null|Undefined} and ContinueIf{Null|Undefined}. New conditional jump bytecodes support this succinctly: JumpIfNull and JumpIfUndefined. Add missing check to BytecodeLabel that could allow multiple forward referencess to the same label which is not supported. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1422033002 Cr-Commit-Position: refs/heads/master@{#31651}
2015-10-29 12:06:00 +00:00
}
}
[Interpreter] Add CallRuntime support to the interpreter. Adds support for calling runtime functions from the interpreter. Adds the CallRuntime bytecode which takes a Runtime::FunctionId of the function to call and the arguments in sequential registers. Adds a InterpreterCEntry builtin to enable the interpreter to enter C++ code based on the functionId. Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall and groups all the interpreter builtins together. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1362383002 Cr-Commit-Position: refs/heads/master@{#31089}
2015-10-02 18:13:41 +00:00
TARGET_TEST_F(InterpreterAssemblerTest, CallRuntime2) {
[Interpreter] Add implementations of arithmetic binary op bytecodes. Adds implementations and tests for the following bytecodes: - Add - Sub - Mul - Div - Mod Also adds the Mod bytecode and adds support to BytecodeGenerator and BytecodeArrayBuilder to enable it's use. The current bytecodes always call through to the JS builtins. This also adds LoadObjectField and CallJSBuiltin operators to the InterpreterAssembler. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1300813005 Cr-Commit-Position: refs/heads/master@{#30352}
2015-08-25 11:31:09 +00:00
TRACED_FOREACH(interpreter::Bytecode, bytecode, kBytecodes) {
Reland of [refactoring] Split CodeAssemblerState out of CodeAssembler This is in preparation for introducing more specialized CodeStubAssembler subclasses. The state object can be handed around, while the Assembler instances are temporary-scoped. BUG=v8:5628 Original review: https://codereview.chromium.org/2498073002/ Review-Url: https://codereview.chromium.org/2502293002 Cr-Commit-Position: refs/heads/master@{#41028}
2016-11-16 11:48:07 +00:00
InterpreterAssemblerTestState state(this, bytecode);
InterpreterAssemblerForTest m(&state, bytecode);
[runtime] Move binary operator fallbacks into the runtime. Replace the ADD, SUB, etc. builtins with proper runtime implementations, and expose them as runtime calls that can be used by the code stubs and the interpreter (for now). Also remove all the support runtime functions for ADD, SUB and friends, namely %NumberAdd, %NumberSub, and so on. R=mstarzinger@chromium.org CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg Review URL: https://codereview.chromium.org/1333843002 Cr-Commit-Position: refs/heads/master@{#30680}
2015-09-10 13:04:15 +00:00
Node* arg1 = m.Int32Constant(2);
Node* arg2 = m.Int32Constant(3);
[Interpreter] Remove register file register and replace with LoadParentFramePointer. Removes the register file machine register from the interpreter and replaces it will loads from the parent frame pointer. As part of this change the raw operand values for register values changes to enable the interpreter to keep using the operand value as the offset from the parent frame pointer. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1894063002 Cr-Commit-Position: refs/heads/master@{#35618}
2016-04-19 12:47:25 +00:00
Node* context = m.Int32Constant(4);
[Interpreter] Make InterpreterAssembler a subclass of CodeStubAssembler. Moves InterpreterAssembler out of the compiler directory and into the interpreter directory. Makes InterpreterAssembler as subclass of CodeStubAssembler. As part of this change, the special bytecode dispatch linkage type is removed and instead we use a InterfaceDispatchDescriptor and a normal CodeStub linkage type. Removes a bunch of duplicated logic in InterpreterAssembler and instead uses the CodeStubAssembler logic. Refactors Interpreter with these changes. Modifies CodeStubAssembler to add the extra operations required by the Interpreter (extra call types, raw memory access and some extra binary ops). Also adds the ability for subclasses to add extra prologue and epilogue operations around calls, which is required for the Interpreter. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1673333004 Cr-Commit-Position: refs/heads/master@{#33873}
2016-02-10 16:38:49 +00:00
Node* call_runtime = m.CallRuntime(Runtime::kAdd, context, arg1, arg2);
[csa] Add constant folding more universally to CodeAssembler operators Contributed by kanghua.yu@intel.com. Bug: None Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9 Reviewed-on: https://chromium-review.googlesource.com/604648 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Pan Deng <pan.deng@intel.com> Cr-Commit-Position: refs/heads/master@{#47968}
2017-09-11 13:44:42 +00:00
EXPECT_THAT(call_runtime, c::IsCall(_, _, arg1, arg2, _,
c::IsInt32Constant(2), context, _, _));
[Interpreter] Add support for property load operations. Adds support for property load operations via Load/KeyedLoad ICs. Adds the following bytecodes: - LoadIC - KeyedLoadIC Also adds support to the interpreter assembler for loading the type feedback vector from the function on the stack, and calling ICs. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1309843007 Cr-Commit-Position: refs/heads/master@{#30543}
2015-09-02 13:03:06 +00:00
}
}
[Interpreter] Add CallRuntime support to the interpreter. Adds support for calling runtime functions from the interpreter. Adds the CallRuntime bytecode which takes a Runtime::FunctionId of the function to call and the arguments in sequential registers. Adds a InterpreterCEntry builtin to enable the interpreter to enter C++ code based on the functionId. Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall and groups all the interpreter builtins together. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1362383002 Cr-Commit-Position: refs/heads/master@{#31089}
2015-10-02 18:13:41 +00:00
TARGET_TEST_F(InterpreterAssemblerTest, CallRuntime) {
[Interpreter] Add support for calling runtime functions which return a pair. Adds support for calling runtime functions which return a pair of values. Adds the bytecode CallRuntimePair. Also adds support to TurboFan for calling stubs which return multiple values. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1568493002 Cr-Commit-Position: refs/heads/master@{#33181}
2016-01-08 15:15:52 +00:00
const int kResultSizes[] = {1, 2};
[Interpreter] Add CallRuntime support to the interpreter. Adds support for calling runtime functions from the interpreter. Adds the CallRuntime bytecode which takes a Runtime::FunctionId of the function to call and the arguments in sequential registers. Adds a InterpreterCEntry builtin to enable the interpreter to enter C++ code based on the functionId. Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall and groups all the interpreter builtins together. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1362383002 Cr-Commit-Position: refs/heads/master@{#31089}
2015-10-02 18:13:41 +00:00
TRACED_FOREACH(interpreter::Bytecode, bytecode, kBytecodes) {
[Interpreter] Add support for calling runtime functions which return a pair. Adds support for calling runtime functions which return a pair of values. Adds the bytecode CallRuntimePair. Also adds support to TurboFan for calling stubs which return multiple values. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1568493002 Cr-Commit-Position: refs/heads/master@{#33181}
2016-01-08 15:15:52 +00:00
TRACED_FOREACH(int, result_size, kResultSizes) {
[ignition] Optimize reloading of registers before Dispatch Before this patch, the registers needed for bytecode dispatch in interpreter handlers were inconsistently stored in the interpreter frame and/or kept in values that remained live across calls. After this patch, these registers are explicitly reloaded after calls, making it possible to elide the spills of those registers before the call in many cases. Some highlights from the CL: * Added methods to the CSA and InterpreterAssembler to efficiently store and load Smis values and Smi interpreter registers on x64 without explicit tagging/untagging. * Created Variables for all of the interpreter-internal values that need to be reloaded before bytecode dispatch at the end of an interpreter handler. * The bytecode offset can be written out early in a handler by marking it has having a call along it's critical path. By moving this early in a handler, it becomes possible to use memory operands for pushes used to marshall parameters when making calls. Change-Id: Icf8d7798789f88a4489e06a7092616bbbb881577 Reviewed-on: https://chromium-review.googlesource.com/442566 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#43260}
2017-02-16 16:54:02 +00:00
if (Bytecodes::IsCallRuntime(bytecode)) {
InterpreterAssemblerTestState state(this, bytecode);
InterpreterAssemblerForTest m(&state, bytecode);
Callable builtin =
CodeFactory::InterpreterCEntry(isolate(), result_size);
Node* function_id = m.Int32Constant(0);
[Interpreter] Refactor bytecode register access. Refactors bytecode register access to avoid having to deal with register indexes directly. - Changes Load/StoreRegister to Load/StoreRegisterAtOperandIndex - Adds RegisterList abstraction for dealin with lists of registers - Adds helpers for Loading / Storing register pairs / triples. Change-Id: I34427e4bd7314dce0230572212580d6a93ccc2d4 Reviewed-on: https://chromium-review.googlesource.com/887062 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#50899}
2018-01-26 10:53:27 +00:00
InterpreterAssembler::RegListNodePair registers(m.IntPtrConstant(1),
m.Int32Constant(2));
[ignition] Optimize reloading of registers before Dispatch Before this patch, the registers needed for bytecode dispatch in interpreter handlers were inconsistently stored in the interpreter frame and/or kept in values that remained live across calls. After this patch, these registers are explicitly reloaded after calls, making it possible to elide the spills of those registers before the call in many cases. Some highlights from the CL: * Added methods to the CSA and InterpreterAssembler to efficiently store and load Smis values and Smi interpreter registers on x64 without explicit tagging/untagging. * Created Variables for all of the interpreter-internal values that need to be reloaded before bytecode dispatch at the end of an interpreter handler. * The bytecode offset can be written out early in a handler by marking it has having a call along it's critical path. By moving this early in a handler, it becomes possible to use memory operands for pushes used to marshall parameters when making calls. Change-Id: Icf8d7798789f88a4489e06a7092616bbbb881577 Reviewed-on: https://chromium-review.googlesource.com/442566 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#43260}
2017-02-16 16:54:02 +00:00
Node* context = m.IntPtrConstant(4);
[presubmit] Enable and fix "build/namespaces" linter check. R=clemensh@chromium.org Change-Id: I42241713b7d14dd1cb321df0570566b0873c10a4 Reviewed-on: https://chromium-review.googlesource.com/647888 Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47793}
2017-09-04 10:47:27 +00:00
Matcher<Node*> function_table = c::IsExternalConstant(
Add external references macro list The macro list avoids duplication in external-reference-table and will allow us to statically determine the size of the table in a follow-up. TBR=mlippautz@chromium.org Bug: v8:6666 Change-Id: I06bb2e8c25970b3c1047dafd6c63d7ca291fe37e Reviewed-on: https://chromium-review.googlesource.com/956187 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#51850}
2018-03-09 15:59:20 +00:00
ExternalReference::runtime_function_table_address_for_unittests(
isolate()));
[csa] Add constant folding more universally to CodeAssembler operators Contributed by kanghua.yu@intel.com. Bug: None Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9 Reviewed-on: https://chromium-review.googlesource.com/604648 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Pan Deng <pan.deng@intel.com> Cr-Commit-Position: refs/heads/master@{#47968}
2017-09-11 13:44:42 +00:00
Matcher<Node*> function = c::IsIntPtrAdd(
[ignition] Optimize reloading of registers before Dispatch Before this patch, the registers needed for bytecode dispatch in interpreter handlers were inconsistently stored in the interpreter frame and/or kept in values that remained live across calls. After this patch, these registers are explicitly reloaded after calls, making it possible to elide the spills of those registers before the call in many cases. Some highlights from the CL: * Added methods to the CSA and InterpreterAssembler to efficiently store and load Smis values and Smi interpreter registers on x64 without explicit tagging/untagging. * Created Variables for all of the interpreter-internal values that need to be reloaded before bytecode dispatch at the end of an interpreter handler. * The bytecode offset can be written out early in a handler by marking it has having a call along it's critical path. By moving this early in a handler, it becomes possible to use memory operands for pushes used to marshall parameters when making calls. Change-Id: Icf8d7798789f88a4489e06a7092616bbbb881577 Reviewed-on: https://chromium-review.googlesource.com/442566 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#43260}
2017-02-16 16:54:02 +00:00
function_table,
[csa] Add constant folding more universally to CodeAssembler operators Contributed by kanghua.yu@intel.com. Bug: None Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9 Reviewed-on: https://chromium-review.googlesource.com/604648 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Pan Deng <pan.deng@intel.com> Cr-Commit-Position: refs/heads/master@{#47968}
2017-09-11 13:44:42 +00:00
c::IsChangeUint32ToWord(c::IsInt32Mul(
[presubmit] Enable and fix "build/namespaces" linter check. R=clemensh@chromium.org Change-Id: I42241713b7d14dd1cb321df0570566b0873c10a4 Reviewed-on: https://chromium-review.googlesource.com/647888 Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47793}
2017-09-04 10:47:27 +00:00
function_id, c::IsInt32Constant(sizeof(Runtime::Function)))));
[ignition] Optimize reloading of registers before Dispatch Before this patch, the registers needed for bytecode dispatch in interpreter handlers were inconsistently stored in the interpreter frame and/or kept in values that remained live across calls. After this patch, these registers are explicitly reloaded after calls, making it possible to elide the spills of those registers before the call in many cases. Some highlights from the CL: * Added methods to the CSA and InterpreterAssembler to efficiently store and load Smis values and Smi interpreter registers on x64 without explicit tagging/untagging. * Created Variables for all of the interpreter-internal values that need to be reloaded before bytecode dispatch at the end of an interpreter handler. * The bytecode offset can be written out early in a handler by marking it has having a call along it's critical path. By moving this early in a handler, it becomes possible to use memory operands for pushes used to marshall parameters when making calls. Change-Id: Icf8d7798789f88a4489e06a7092616bbbb881577 Reviewed-on: https://chromium-review.googlesource.com/442566 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#43260}
2017-02-16 16:54:02 +00:00
Matcher<Node*> function_entry =
m.IsLoad(MachineType::Pointer(), function,
[csa] Add constant folding more universally to CodeAssembler operators Contributed by kanghua.yu@intel.com. Bug: None Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9 Reviewed-on: https://chromium-review.googlesource.com/604648 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Pan Deng <pan.deng@intel.com> Cr-Commit-Position: refs/heads/master@{#47968}
2017-09-11 13:44:42 +00:00
c::IsIntPtrConstant(offsetof(Runtime::Function, entry)));
[ignition] Optimize reloading of registers before Dispatch Before this patch, the registers needed for bytecode dispatch in interpreter handlers were inconsistently stored in the interpreter frame and/or kept in values that remained live across calls. After this patch, these registers are explicitly reloaded after calls, making it possible to elide the spills of those registers before the call in many cases. Some highlights from the CL: * Added methods to the CSA and InterpreterAssembler to efficiently store and load Smis values and Smi interpreter registers on x64 without explicit tagging/untagging. * Created Variables for all of the interpreter-internal values that need to be reloaded before bytecode dispatch at the end of an interpreter handler. * The bytecode offset can be written out early in a handler by marking it has having a call along it's critical path. By moving this early in a handler, it becomes possible to use memory operands for pushes used to marshall parameters when making calls. Change-Id: Icf8d7798789f88a4489e06a7092616bbbb881577 Reviewed-on: https://chromium-review.googlesource.com/442566 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#43260}
2017-02-16 16:54:02 +00:00
[Interpreter] Refactor bytecode register access. Refactors bytecode register access to avoid having to deal with register indexes directly. - Changes Load/StoreRegister to Load/StoreRegisterAtOperandIndex - Adds RegisterList abstraction for dealin with lists of registers - Adds helpers for Loading / Storing register pairs / triples. Change-Id: I34427e4bd7314dce0230572212580d6a93ccc2d4 Reviewed-on: https://chromium-review.googlesource.com/887062 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#50899}
2018-01-26 10:53:27 +00:00
Node* call_runtime =
m.CallRuntimeN(function_id, context, registers, result_size);
EXPECT_THAT(
call_runtime,
c::IsCall(_, c::IsHeapConstant(builtin.code()),
registers.reg_count(), registers.base_reg_location(),
function_entry, context, _, _));
[ignition] Optimize reloading of registers before Dispatch Before this patch, the registers needed for bytecode dispatch in interpreter handlers were inconsistently stored in the interpreter frame and/or kept in values that remained live across calls. After this patch, these registers are explicitly reloaded after calls, making it possible to elide the spills of those registers before the call in many cases. Some highlights from the CL: * Added methods to the CSA and InterpreterAssembler to efficiently store and load Smis values and Smi interpreter registers on x64 without explicit tagging/untagging. * Created Variables for all of the interpreter-internal values that need to be reloaded before bytecode dispatch at the end of an interpreter handler. * The bytecode offset can be written out early in a handler by marking it has having a call along it's critical path. By moving this early in a handler, it becomes possible to use memory operands for pushes used to marshall parameters when making calls. Change-Id: Icf8d7798789f88a4489e06a7092616bbbb881577 Reviewed-on: https://chromium-review.googlesource.com/442566 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#43260}
2017-02-16 16:54:02 +00:00
}
[Interpreter] Add support for calling runtime functions which return a pair. Adds support for calling runtime functions which return a pair of values. Adds the bytecode CallRuntimePair. Also adds support to TurboFan for calling stubs which return multiple values. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1568493002 Cr-Commit-Position: refs/heads/master@{#33181}
2016-01-08 15:15:52 +00:00
}
[Interpreter] Add CallRuntime support to the interpreter. Adds support for calling runtime functions from the interpreter. Adds the CallRuntime bytecode which takes a Runtime::FunctionId of the function to call and the arguments in sequential registers. Adds a InterpreterCEntry builtin to enable the interpreter to enter C++ code based on the functionId. Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall and groups all the interpreter builtins together. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1362383002 Cr-Commit-Position: refs/heads/master@{#31089}
2015-10-02 18:13:41 +00:00
}
}
Rename TypeFeedbackVector to FeedbackVector. ... and TypeFeedbackMetadata to FeedbackMetadata. BUG= Change-Id: I2556d1c2a8f37b8cf3d532cc98d973b6dc7e9e6c Reviewed-on: https://chromium-review.googlesource.com/439244 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/master@{#42999}
2017-02-07 14:05:02 +00:00
TARGET_TEST_F(InterpreterAssemblerTest, LoadFeedbackVector) {
[Interpreter] Add support for property load operations. Adds support for property load operations via Load/KeyedLoad ICs. Adds the following bytecodes: - LoadIC - KeyedLoadIC Also adds support to the interpreter assembler for loading the type feedback vector from the function on the stack, and calling ICs. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1309843007 Cr-Commit-Position: refs/heads/master@{#30543}
2015-09-02 13:03:06 +00:00
TRACED_FOREACH(interpreter::Bytecode, bytecode, kBytecodes) {
Reland of [refactoring] Split CodeAssemblerState out of CodeAssembler This is in preparation for introducing more specialized CodeStubAssembler subclasses. The state object can be handed around, while the Assembler instances are temporary-scoped. BUG=v8:5628 Original review: https://codereview.chromium.org/2498073002/ Review-Url: https://codereview.chromium.org/2502293002 Cr-Commit-Position: refs/heads/master@{#41028}
2016-11-16 11:48:07 +00:00
InterpreterAssemblerTestState state(this, bytecode);
InterpreterAssemblerForTest m(&state, bytecode);
Rename TypeFeedbackVector to FeedbackVector. ... and TypeFeedbackMetadata to FeedbackMetadata. BUG= Change-Id: I2556d1c2a8f37b8cf3d532cc98d973b6dc7e9e6c Reviewed-on: https://chromium-review.googlesource.com/439244 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/master@{#42999}
2017-02-07 14:05:02 +00:00
Node* feedback_vector = m.LoadFeedbackVector();
[Interpreter] Add support for property load operations. Adds support for property load operations via Load/KeyedLoad ICs. Adds the following bytecodes: - LoadIC - KeyedLoadIC Also adds support to the interpreter assembler for loading the type feedback vector from the function on the stack, and calling ICs. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1309843007 Cr-Commit-Position: refs/heads/master@{#30543}
2015-09-02 13:03:06 +00:00
[Interpreter] Remove register file register and replace with LoadParentFramePointer. Removes the register file machine register from the interpreter and replaces it will loads from the parent frame pointer. As part of this change the raw operand values for register values changes to enable the interpreter to keep using the operand value as the offset from the parent frame pointer. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1894063002 Cr-Commit-Position: refs/heads/master@{#35618}
2016-04-19 12:47:25 +00:00
Matcher<Node*> load_function_matcher =
[presubmit] Enable and fix "build/namespaces" linter check. R=clemensh@chromium.org Change-Id: I42241713b7d14dd1cb321df0570566b0873c10a4 Reviewed-on: https://chromium-review.googlesource.com/647888 Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47793}
2017-09-04 10:47:27 +00:00
m.IsLoad(MachineType::AnyTagged(), c::IsLoadParentFramePointer(),
[csa] Add constant folding more universally to CodeAssembler operators Contributed by kanghua.yu@intel.com. Bug: None Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9 Reviewed-on: https://chromium-review.googlesource.com/604648 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Pan Deng <pan.deng@intel.com> Cr-Commit-Position: refs/heads/master@{#47968}
2017-09-11 13:44:42 +00:00
c::IsIntPtrConstant(Register::function_closure().ToOperand()
<< kPointerSizeLog2));
[cleanup] Introduce a dedicated FeedbackCell. This is preparatory cleanup work for eventually tracking the functions (rather than concrete closures) in the CALL_IC, also for builtins like the default PromiseCapability [[Resolve]] and [[Reject]] functions. It adds a new FeedbackCell type, which is used by JSFunctions consistently now to reference the feedback vector (or undefined if not the function is not compiled yet or is a native/asm.js function). This also changes the calling convention for FastNewClosure builtin and the JSCreateClosure operator in TurboFan to carry the FeedbackCell here instead of the parent FeedbackVector and the slot index. In addition we eliminate the now unused %InterpreterNewClosure runtime function. Bug: v8:2206, v8:7253, v8:7310 Change-Id: Ib4ce456e276e0273e57c163dcdd0b33abf863656 Reviewed-on: https://chromium-review.googlesource.com/928403 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#51474}
2018-02-22 12:04:01 +00:00
Matcher<Node*> load_vector_cell_matcher = m.IsLoad(
MachineType::AnyTagged(), load_function_matcher,
c::IsIntPtrConstant(JSFunction::kFeedbackCellOffset - kHeapObjectTag));
[TypeFeedbackVector] Root feedback vectors at function literal site. TypeFeedbackVectors are strongly rooted by a closure. However, in modern JavaScript closures are created and abandoned more freely. An important closure may not be present in the root-set at time of garbage collection, even though we've cached optimized code and use it regularly. For example, consider leaf functions in an event dispatching system. They may well be "hot," but tragically non-present when we collect the heap. Until now, we've relied on a weak root to cache the feedback vector in this case. Since there is no way to signal intent or relative importance, this weak root is as susceptible to clearing as any other weak root at garbage collection time. Meanwhile, the feedback vector has become more important. All of our ICs store their data there. Literal and regex boilerplates are stored there. If we lose the vector, then we not only lose optimized code built from it, we also lose the very feedback which allowed us to create that optimized code. Therefore it's vital to express that dependency through the root set. This CL does this by creating a strong link to a feedback vector at the instantiation site of the function closure. This instantiation site is in the code and feedback vector of the outer closure. BUG=v8:5456 Review-Url: https://codereview.chromium.org/2674593003 Cr-Commit-Position: refs/heads/master@{#42953}
2017-02-06 10:18:05 +00:00
EXPECT_THAT(
feedback_vector,
m.IsLoad(MachineType::AnyTagged(), load_vector_cell_matcher,
[csa] Add constant folding more universally to CodeAssembler operators Contributed by kanghua.yu@intel.com. Bug: None Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9 Reviewed-on: https://chromium-review.googlesource.com/604648 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Pan Deng <pan.deng@intel.com> Cr-Commit-Position: refs/heads/master@{#47968}
2017-09-11 13:44:42 +00:00
c::IsIntPtrConstant(Cell::kValueOffset - kHeapObjectTag)));
[Interpreter] Add implementations of arithmetic binary op bytecodes. Adds implementations and tests for the following bytecodes: - Add - Sub - Mul - Div - Mod Also adds the Mod bytecode and adds support to BytecodeGenerator and BytecodeArrayBuilder to enable it's use. The current bytecodes always call through to the JS builtins. This also adds LoadObjectField and CallJSBuiltin operators to the InterpreterAssembler. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1300813005 Cr-Commit-Position: refs/heads/master@{#30352}
2015-08-25 11:31:09 +00:00
}
}
[jumbo] fix another set of unittest compilation errors This makes jumbo_file_merge_limit=50 work again. Bug: chromium:770684 Change-Id: I5db6566da876d71ea6ba50ff03b7652074b0a35f Reviewed-on: https://chromium-review.googlesource.com/725818 Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Mostyn Bramley-Moore <mostynb@vewd.com> Cr-Commit-Position: refs/heads/master@{#48728}
2017-10-18 17:01:45 +00:00
} // namespace interpreter_assembler_unittest
[Interpreter] Make InterpreterAssembler a subclass of CodeStubAssembler. Moves InterpreterAssembler out of the compiler directory and into the interpreter directory. Makes InterpreterAssembler as subclass of CodeStubAssembler. As part of this change, the special bytecode dispatch linkage type is removed and instead we use a InterfaceDispatchDescriptor and a normal CodeStub linkage type. Removes a bunch of duplicated logic in InterpreterAssembler and instead uses the CodeStubAssembler logic. Refactors Interpreter with these changes. Modifies CodeStubAssembler to add the extra operations required by the Interpreter (extra call types, raw memory access and some extra binary ops). Also adds the ability for subclasses to add extra prologue and epilogue operations around calls, which is required for the Interpreter. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1673333004 Cr-Commit-Position: refs/heads/master@{#33873}
2016-02-10 16:38:49 +00:00
} // namespace interpreter
[interpreter] Add basic framework for bytecode handler code generation. Adds basic support for generation of interpreter bytecode handler code snippets. The InterpreterAssembler class exposes a set of low level, interpreter specific operations which can be used to build a Turbofan graph. The Interpreter class generates a bytecode handler snippet for each bytecode by assembling operations using an InterpreterAssembler. Currently only two simple bytecodes are supported: LoadLiteral0 and Return. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1239793002 Cr-Commit-Position: refs/heads/master@{#29814}
2015-07-23 14:21:26 +00:00
} // namespace internal
} // namespace v8
Reference in New Issue Copy Permalink