AuroraMiddleware/v8
1
0
Fork 0
Code Issues 2 Pull Requests Releases Wiki Activity
d5fbf0edcf
v8/test/unittests/interpreter/bytecode-array-random-iterator-unittest.cc

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

996 lines
43 KiB
C++
Raw Normal View History

[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +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.
#include "src/v8.h"
#include "src/interpreter/bytecode-array-builder.h"
#include "src/interpreter/bytecode-array-random-iterator.h"
include fixing: api.h shouldn't include objects-inl.h Downside: this adds all kinds of weird includes in the .cc files. (See design doc linked in the bug.) BUG=v8:5402 Review-Url: https://codereview.chromium.org/2622503002 Cr-Commit-Position: refs/heads/master@{#42140}
2017-01-09 13:43:28 +00:00
#include "src/objects-inl.h"
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
#include "test/unittests/test-utils.h"
namespace v8 {
namespace internal {
namespace interpreter {
class BytecodeArrayRandomIteratorTest : public TestWithIsolateAndZone {
public:
BytecodeArrayRandomIteratorTest() {}
~BytecodeArrayRandomIteratorTest() override {}
};
TEST_F(BytecodeArrayRandomIteratorTest, InvalidBeforeStart) {
// Use a builder to create an array with containing multiple bytecodes
// with 0, 1 and 2 operands.
[Cleanup][Interpreter] Move feedback slot allocation to bytecode generator Moves the feedback vector slot allocation out of ast-numbering and into bytecode generation directly. This has a couple of benifits, including reduced AST size, avoid code duplication and reduced feedback vector sizes in many cases due to only allocating slots when needed. Also removes AstProperties since this is no longer needed. AstNumbering is now only used to allocate suspend ids for generators. BUG=v8:6921 Change-Id: I103e8593c94ef5b2e56c34ef4f77bd6e7d64796f Reviewed-on: https://chromium-review.googlesource.com/722959 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48757}
2017-10-19 15:12:42 +00:00
FeedbackVectorSpec feedback_spec(zone());
[Compiler] Remove isolate from CompilationInfo. Removes Isolate from compilation info and instead threads isolate through function calls. This ensures that we can't access the isolate from background thread compilations. BUG=v8:5203 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I9a4e1cd67c4736e36f609360b996fb55166a1c50 Reviewed-on: https://chromium-review.googlesource.com/751745 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#49386}
2017-11-15 14:36:57 +00:00
BytecodeArrayBuilder builder(zone(), 3, 3, &feedback_spec);
[ignition] Remove handles from bytecode generation Removes handles from bytecode generation, instead storing un-internalized AstValues (and other, similar values such as Scopes and AstRawStrings) in the constant array builder. This will allow us in the future to generate the bytecode before internalizing the AST. BUG=v8:5832 Change-Id: I3b8be8f7329a484eb1e5d12808b001d3475239da Reviewed-on: https://chromium-review.googlesource.com/439326 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#43115}
2017-02-10 17:22:45 +00:00
AstValueFactory ast_factory(zone(), isolate()->ast_string_constants(),
isolate()->heap()->HashSeed());
[ast] Move AstValue implementation into Literal This eliminates the AstValue class, effectively moving its implementation into the Literal AstNode. This should cause no difference in behavior, but it does signal some shifts in the underlying system. Biggest changes include: - Reduction in AST memory usage - No duplicate HeapNumbers in Ignition constant pools - Non-String values are allocated either at constant pool creation time (or at boilerplate creation time for literals), rather than at AstValueFactory::Internalize() time. There are a variety of test-only/debug-only changes due to these switches as well. Bug: v8:6984 Change-Id: I5f178040ce2796d4e7370c24d1063419e1c843a1 Reviewed-on: https://chromium-review.googlesource.com/731111 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#49013}
2017-10-27 19:53:15 +00:00
double heap_num_0 = 2.718;
double heap_num_1 = 2.0 * Smi::kMaxValue;
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
Smi* zero = Smi::kZero;
Smi* smi_0 = Smi::FromInt(64);
Smi* smi_1 = Smi::FromInt(-65536);
Register reg_0(0);
Register reg_1(1);
RegisterList pair(0, 2);
RegisterList triple(0, 3);
Register param = Register::FromParameterIndex(2, builder.parameter_count());
[ignition] Remove handles from bytecode generation Removes handles from bytecode generation, instead storing un-internalized AstValues (and other, similar values such as Scopes and AstRawStrings) in the constant array builder. This will allow us in the future to generate the bytecode before internalizing the AST. BUG=v8:5832 Change-Id: I3b8be8f7329a484eb1e5d12808b001d3475239da Reviewed-on: https://chromium-review.googlesource.com/439326 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#43115}
2017-02-10 17:22:45 +00:00
const AstRawString* name = ast_factory.GetOneByteString("abc");
[Cleanup][Interpreter] Move feedback slot allocation to bytecode generator Moves the feedback vector slot allocation out of ast-numbering and into bytecode generation directly. This has a couple of benifits, including reduced AST size, avoid code duplication and reduced feedback vector sizes in many cases due to only allocating slots when needed. Also removes AstProperties since this is no longer needed. AstNumbering is now only used to allocate suspend ids for generators. BUG=v8:6921 Change-Id: I103e8593c94ef5b2e56c34ef4f77bd6e7d64796f Reviewed-on: https://chromium-review.googlesource.com/722959 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48757}
2017-10-19 15:12:42 +00:00
uint32_t feedback_slot = feedback_spec.AddLoadICSlot().ToInt();
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
builder.LoadLiteral(heap_num_0)
.StoreAccumulatorInRegister(reg_0)
.LoadLiteral(heap_num_1)
.StoreAccumulatorInRegister(reg_0)
.LoadLiteral(zero)
.StoreAccumulatorInRegister(reg_0)
.LoadLiteral(smi_0)
.StackCheck(0)
.StoreAccumulatorInRegister(reg_0)
.LoadLiteral(smi_1)
.StackCheck(1)
.StoreAccumulatorInRegister(reg_1)
.LoadAccumulatorWithRegister(reg_0)
.BinaryOperation(Token::Value::ADD, reg_0, 2)
.StoreAccumulatorInRegister(reg_1)
.LoadNamedProperty(reg_1, name, feedback_slot)
.BinaryOperation(Token::Value::ADD, reg_0, 3)
.StoreAccumulatorInRegister(param)
.CallRuntimeForPair(Runtime::kLoadLookupSlotForCall, param, pair)
[turbofan] Optimize fast enum cache driven for..in. This CL adds support to optimize for..in in fast enum-cache mode to the same degree that it was optimized in Crankshaft, without adding the same deoptimization loop that Crankshaft had with missing enum cache indices. That means code like for (var k in o) { var v = o[k]; // ... } and code like for (var k in o) { if (Object.prototype.hasOwnProperty.call(o, k)) { var v = o[k]; // ... } } which follows the https://eslint.org/docs/rules/guard-for-in linter rule, can now utilize the enum cache indices if o has only fast properties on the receiver, which speeds up the access o[k] significantly and reduces the pollution of the global megamorphic stub cache. For example the micro-benchmark in the tracking bug v8:6702 now runs faster than ever before: forIn: 1516 ms. forInHasOwnProperty: 1674 ms. forInHasOwnPropertySafe: 1595 ms. forInSum: 2051 ms. forInSumSafe: 2215 ms. Compared to numbers from V8 5.8 which is the last version running with Crankshaft forIn: 1641 ms. forInHasOwnProperty: 1719 ms. forInHasOwnPropertySafe: 1802 ms. forInSum: 2226 ms. forInSumSafe: 2409 ms. and V8 6.0 which is the current stable version with TurboFan: forIn: 1713 ms. forInHasOwnProperty: 5417 ms. forInHasOwnPropertySafe: 5324 ms. forInSum: 7556 ms. forInSumSafe: 11067 ms. It also improves the throughput on the string-fasta benchmark by around 7-10%, and there seems to be a ~5% improvement on the Speedometer/React benchmark locally. For this to work, the ForInPrepare bytecode was split into ForInEnumerate and ForInPrepare, which is very similar to how it was handled in Fullcodegen initially. In TurboFan we introduce a new operator LoadFieldByIndex that does the dynamic property load. This also removes the CheckMapValue operator again in favor of just using LoadField, ReferenceEqual and CheckIf, which work automatically with the EscapeAnalysis and the BranchConditionElimination. Bug: v8:6702 Change-Id: I91235413eea478ba77ace7bd14bb2f62e155dd9a Reviewed-on: https://chromium-review.googlesource.com/645949 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#47768}
2017-09-01 10:49:06 +00:00
.ForInPrepare(triple, feedback_slot)
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
.CallRuntime(Runtime::kLoadIC_Miss, reg_0)
.Debugger()
.Return();
[ignition] Remove handles from bytecode generation Removes handles from bytecode generation, instead storing un-internalized AstValues (and other, similar values such as Scopes and AstRawStrings) in the constant array builder. This will allow us in the future to generate the bytecode before internalizing the AST. BUG=v8:5832 Change-Id: I3b8be8f7329a484eb1e5d12808b001d3475239da Reviewed-on: https://chromium-review.googlesource.com/439326 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#43115}
2017-02-10 17:22:45 +00:00
ast_factory.Internalize(isolate());
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
Handle<BytecodeArray> bytecodeArray = builder.ToBytecodeArray(isolate());
BytecodeArrayRandomIterator iterator(bytecodeArray, zone());
iterator.GoToStart();
ASSERT_TRUE(iterator.IsValid());
--iterator;
ASSERT_FALSE(iterator.IsValid());
}
TEST_F(BytecodeArrayRandomIteratorTest, InvalidAfterEnd) {
// Use a builder to create an array with containing multiple bytecodes
// with 0, 1 and 2 operands.
[Cleanup][Interpreter] Move feedback slot allocation to bytecode generator Moves the feedback vector slot allocation out of ast-numbering and into bytecode generation directly. This has a couple of benifits, including reduced AST size, avoid code duplication and reduced feedback vector sizes in many cases due to only allocating slots when needed. Also removes AstProperties since this is no longer needed. AstNumbering is now only used to allocate suspend ids for generators. BUG=v8:6921 Change-Id: I103e8593c94ef5b2e56c34ef4f77bd6e7d64796f Reviewed-on: https://chromium-review.googlesource.com/722959 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48757}
2017-10-19 15:12:42 +00:00
FeedbackVectorSpec feedback_spec(zone());
[Compiler] Remove isolate from CompilationInfo. Removes Isolate from compilation info and instead threads isolate through function calls. This ensures that we can't access the isolate from background thread compilations. BUG=v8:5203 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I9a4e1cd67c4736e36f609360b996fb55166a1c50 Reviewed-on: https://chromium-review.googlesource.com/751745 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#49386}
2017-11-15 14:36:57 +00:00
BytecodeArrayBuilder builder(zone(), 3, 3, &feedback_spec);
[ignition] Remove handles from bytecode generation Removes handles from bytecode generation, instead storing un-internalized AstValues (and other, similar values such as Scopes and AstRawStrings) in the constant array builder. This will allow us in the future to generate the bytecode before internalizing the AST. BUG=v8:5832 Change-Id: I3b8be8f7329a484eb1e5d12808b001d3475239da Reviewed-on: https://chromium-review.googlesource.com/439326 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#43115}
2017-02-10 17:22:45 +00:00
AstValueFactory ast_factory(zone(), isolate()->ast_string_constants(),
isolate()->heap()->HashSeed());
[ast] Move AstValue implementation into Literal This eliminates the AstValue class, effectively moving its implementation into the Literal AstNode. This should cause no difference in behavior, but it does signal some shifts in the underlying system. Biggest changes include: - Reduction in AST memory usage - No duplicate HeapNumbers in Ignition constant pools - Non-String values are allocated either at constant pool creation time (or at boilerplate creation time for literals), rather than at AstValueFactory::Internalize() time. There are a variety of test-only/debug-only changes due to these switches as well. Bug: v8:6984 Change-Id: I5f178040ce2796d4e7370c24d1063419e1c843a1 Reviewed-on: https://chromium-review.googlesource.com/731111 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#49013}
2017-10-27 19:53:15 +00:00
double heap_num_0 = 2.718;
double heap_num_1 = 2.0 * Smi::kMaxValue;
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
Smi* zero = Smi::kZero;
Smi* smi_0 = Smi::FromInt(64);
Smi* smi_1 = Smi::FromInt(-65536);
Register reg_0(0);
Register reg_1(1);
RegisterList pair(0, 2);
RegisterList triple(0, 3);
Register param = Register::FromParameterIndex(2, builder.parameter_count());
[ignition] Remove handles from bytecode generation Removes handles from bytecode generation, instead storing un-internalized AstValues (and other, similar values such as Scopes and AstRawStrings) in the constant array builder. This will allow us in the future to generate the bytecode before internalizing the AST. BUG=v8:5832 Change-Id: I3b8be8f7329a484eb1e5d12808b001d3475239da Reviewed-on: https://chromium-review.googlesource.com/439326 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#43115}
2017-02-10 17:22:45 +00:00
const AstRawString* name = ast_factory.GetOneByteString("abc");
[Cleanup][Interpreter] Move feedback slot allocation to bytecode generator Moves the feedback vector slot allocation out of ast-numbering and into bytecode generation directly. This has a couple of benifits, including reduced AST size, avoid code duplication and reduced feedback vector sizes in many cases due to only allocating slots when needed. Also removes AstProperties since this is no longer needed. AstNumbering is now only used to allocate suspend ids for generators. BUG=v8:6921 Change-Id: I103e8593c94ef5b2e56c34ef4f77bd6e7d64796f Reviewed-on: https://chromium-review.googlesource.com/722959 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48757}
2017-10-19 15:12:42 +00:00
uint32_t feedback_slot = feedback_spec.AddLoadICSlot().ToInt();
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
builder.LoadLiteral(heap_num_0)
.StoreAccumulatorInRegister(reg_0)
.LoadLiteral(heap_num_1)
.StoreAccumulatorInRegister(reg_0)
.LoadLiteral(zero)
.StoreAccumulatorInRegister(reg_0)
.LoadLiteral(smi_0)
.StackCheck(0)
.StoreAccumulatorInRegister(reg_0)
.LoadLiteral(smi_1)
.StackCheck(1)
.StoreAccumulatorInRegister(reg_1)
.LoadAccumulatorWithRegister(reg_0)
.BinaryOperation(Token::Value::ADD, reg_0, 2)
.StoreAccumulatorInRegister(reg_1)
.LoadNamedProperty(reg_1, name, feedback_slot)
.BinaryOperation(Token::Value::ADD, reg_0, 3)
.StoreAccumulatorInRegister(param)
.CallRuntimeForPair(Runtime::kLoadLookupSlotForCall, param, pair)
[turbofan] Optimize fast enum cache driven for..in. This CL adds support to optimize for..in in fast enum-cache mode to the same degree that it was optimized in Crankshaft, without adding the same deoptimization loop that Crankshaft had with missing enum cache indices. That means code like for (var k in o) { var v = o[k]; // ... } and code like for (var k in o) { if (Object.prototype.hasOwnProperty.call(o, k)) { var v = o[k]; // ... } } which follows the https://eslint.org/docs/rules/guard-for-in linter rule, can now utilize the enum cache indices if o has only fast properties on the receiver, which speeds up the access o[k] significantly and reduces the pollution of the global megamorphic stub cache. For example the micro-benchmark in the tracking bug v8:6702 now runs faster than ever before: forIn: 1516 ms. forInHasOwnProperty: 1674 ms. forInHasOwnPropertySafe: 1595 ms. forInSum: 2051 ms. forInSumSafe: 2215 ms. Compared to numbers from V8 5.8 which is the last version running with Crankshaft forIn: 1641 ms. forInHasOwnProperty: 1719 ms. forInHasOwnPropertySafe: 1802 ms. forInSum: 2226 ms. forInSumSafe: 2409 ms. and V8 6.0 which is the current stable version with TurboFan: forIn: 1713 ms. forInHasOwnProperty: 5417 ms. forInHasOwnPropertySafe: 5324 ms. forInSum: 7556 ms. forInSumSafe: 11067 ms. It also improves the throughput on the string-fasta benchmark by around 7-10%, and there seems to be a ~5% improvement on the Speedometer/React benchmark locally. For this to work, the ForInPrepare bytecode was split into ForInEnumerate and ForInPrepare, which is very similar to how it was handled in Fullcodegen initially. In TurboFan we introduce a new operator LoadFieldByIndex that does the dynamic property load. This also removes the CheckMapValue operator again in favor of just using LoadField, ReferenceEqual and CheckIf, which work automatically with the EscapeAnalysis and the BranchConditionElimination. Bug: v8:6702 Change-Id: I91235413eea478ba77ace7bd14bb2f62e155dd9a Reviewed-on: https://chromium-review.googlesource.com/645949 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#47768}
2017-09-01 10:49:06 +00:00
.ForInPrepare(triple, feedback_slot)
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
.CallRuntime(Runtime::kLoadIC_Miss, reg_0)
.Debugger()
.Return();
[ignition] Remove handles from bytecode generation Removes handles from bytecode generation, instead storing un-internalized AstValues (and other, similar values such as Scopes and AstRawStrings) in the constant array builder. This will allow us in the future to generate the bytecode before internalizing the AST. BUG=v8:5832 Change-Id: I3b8be8f7329a484eb1e5d12808b001d3475239da Reviewed-on: https://chromium-review.googlesource.com/439326 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#43115}
2017-02-10 17:22:45 +00:00
ast_factory.Internalize(isolate());
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
Handle<BytecodeArray> bytecodeArray = builder.ToBytecodeArray(isolate());
BytecodeArrayRandomIterator iterator(bytecodeArray, zone());
iterator.GoToEnd();
ASSERT_TRUE(iterator.IsValid());
++iterator;
ASSERT_FALSE(iterator.IsValid());
}
TEST_F(BytecodeArrayRandomIteratorTest, AccessesFirst) {
// Use a builder to create an array with containing multiple bytecodes
// with 0, 1 and 2 operands.
[Cleanup][Interpreter] Move feedback slot allocation to bytecode generator Moves the feedback vector slot allocation out of ast-numbering and into bytecode generation directly. This has a couple of benifits, including reduced AST size, avoid code duplication and reduced feedback vector sizes in many cases due to only allocating slots when needed. Also removes AstProperties since this is no longer needed. AstNumbering is now only used to allocate suspend ids for generators. BUG=v8:6921 Change-Id: I103e8593c94ef5b2e56c34ef4f77bd6e7d64796f Reviewed-on: https://chromium-review.googlesource.com/722959 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48757}
2017-10-19 15:12:42 +00:00
FeedbackVectorSpec feedback_spec(zone());
[Compiler] Remove isolate from CompilationInfo. Removes Isolate from compilation info and instead threads isolate through function calls. This ensures that we can't access the isolate from background thread compilations. BUG=v8:5203 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I9a4e1cd67c4736e36f609360b996fb55166a1c50 Reviewed-on: https://chromium-review.googlesource.com/751745 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#49386}
2017-11-15 14:36:57 +00:00
BytecodeArrayBuilder builder(zone(), 3, 3, &feedback_spec);
[ignition] Remove handles from bytecode generation Removes handles from bytecode generation, instead storing un-internalized AstValues (and other, similar values such as Scopes and AstRawStrings) in the constant array builder. This will allow us in the future to generate the bytecode before internalizing the AST. BUG=v8:5832 Change-Id: I3b8be8f7329a484eb1e5d12808b001d3475239da Reviewed-on: https://chromium-review.googlesource.com/439326 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#43115}
2017-02-10 17:22:45 +00:00
AstValueFactory ast_factory(zone(), isolate()->ast_string_constants(),
isolate()->heap()->HashSeed());
[ast] Move AstValue implementation into Literal This eliminates the AstValue class, effectively moving its implementation into the Literal AstNode. This should cause no difference in behavior, but it does signal some shifts in the underlying system. Biggest changes include: - Reduction in AST memory usage - No duplicate HeapNumbers in Ignition constant pools - Non-String values are allocated either at constant pool creation time (or at boilerplate creation time for literals), rather than at AstValueFactory::Internalize() time. There are a variety of test-only/debug-only changes due to these switches as well. Bug: v8:6984 Change-Id: I5f178040ce2796d4e7370c24d1063419e1c843a1 Reviewed-on: https://chromium-review.googlesource.com/731111 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#49013}
2017-10-27 19:53:15 +00:00
double heap_num_0 = 2.718;
double heap_num_1 = 2.0 * Smi::kMaxValue;
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
Smi* zero = Smi::kZero;
Smi* smi_0 = Smi::FromInt(64);
Smi* smi_1 = Smi::FromInt(-65536);
Register reg_0(0);
Register reg_1(1);
RegisterList pair(0, 2);
RegisterList triple(0, 3);
Register param = Register::FromParameterIndex(2, builder.parameter_count());
[ignition] Remove handles from bytecode generation Removes handles from bytecode generation, instead storing un-internalized AstValues (and other, similar values such as Scopes and AstRawStrings) in the constant array builder. This will allow us in the future to generate the bytecode before internalizing the AST. BUG=v8:5832 Change-Id: I3b8be8f7329a484eb1e5d12808b001d3475239da Reviewed-on: https://chromium-review.googlesource.com/439326 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#43115}
2017-02-10 17:22:45 +00:00
const AstRawString* name = ast_factory.GetOneByteString("abc");
[Cleanup][Interpreter] Move feedback slot allocation to bytecode generator Moves the feedback vector slot allocation out of ast-numbering and into bytecode generation directly. This has a couple of benifits, including reduced AST size, avoid code duplication and reduced feedback vector sizes in many cases due to only allocating slots when needed. Also removes AstProperties since this is no longer needed. AstNumbering is now only used to allocate suspend ids for generators. BUG=v8:6921 Change-Id: I103e8593c94ef5b2e56c34ef4f77bd6e7d64796f Reviewed-on: https://chromium-review.googlesource.com/722959 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48757}
2017-10-19 15:12:42 +00:00
uint32_t feedback_slot = feedback_spec.AddLoadICSlot().ToInt();
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
builder.LoadLiteral(heap_num_0)
.StoreAccumulatorInRegister(reg_0)
.LoadLiteral(heap_num_1)
.StoreAccumulatorInRegister(reg_0)
.LoadLiteral(zero)
.StoreAccumulatorInRegister(reg_0)
.LoadLiteral(smi_0)
.StackCheck(0)
.StoreAccumulatorInRegister(reg_0)
.LoadLiteral(smi_1)
.StackCheck(1)
.StoreAccumulatorInRegister(reg_1)
.LoadAccumulatorWithRegister(reg_0)
.BinaryOperation(Token::Value::ADD, reg_0, 2)
.StoreAccumulatorInRegister(reg_1)
.LoadNamedProperty(reg_1, name, feedback_slot)
.BinaryOperation(Token::Value::ADD, reg_0, 3)
.StoreAccumulatorInRegister(param)
.CallRuntimeForPair(Runtime::kLoadLookupSlotForCall, param, pair)
[turbofan] Optimize fast enum cache driven for..in. This CL adds support to optimize for..in in fast enum-cache mode to the same degree that it was optimized in Crankshaft, without adding the same deoptimization loop that Crankshaft had with missing enum cache indices. That means code like for (var k in o) { var v = o[k]; // ... } and code like for (var k in o) { if (Object.prototype.hasOwnProperty.call(o, k)) { var v = o[k]; // ... } } which follows the https://eslint.org/docs/rules/guard-for-in linter rule, can now utilize the enum cache indices if o has only fast properties on the receiver, which speeds up the access o[k] significantly and reduces the pollution of the global megamorphic stub cache. For example the micro-benchmark in the tracking bug v8:6702 now runs faster than ever before: forIn: 1516 ms. forInHasOwnProperty: 1674 ms. forInHasOwnPropertySafe: 1595 ms. forInSum: 2051 ms. forInSumSafe: 2215 ms. Compared to numbers from V8 5.8 which is the last version running with Crankshaft forIn: 1641 ms. forInHasOwnProperty: 1719 ms. forInHasOwnPropertySafe: 1802 ms. forInSum: 2226 ms. forInSumSafe: 2409 ms. and V8 6.0 which is the current stable version with TurboFan: forIn: 1713 ms. forInHasOwnProperty: 5417 ms. forInHasOwnPropertySafe: 5324 ms. forInSum: 7556 ms. forInSumSafe: 11067 ms. It also improves the throughput on the string-fasta benchmark by around 7-10%, and there seems to be a ~5% improvement on the Speedometer/React benchmark locally. For this to work, the ForInPrepare bytecode was split into ForInEnumerate and ForInPrepare, which is very similar to how it was handled in Fullcodegen initially. In TurboFan we introduce a new operator LoadFieldByIndex that does the dynamic property load. This also removes the CheckMapValue operator again in favor of just using LoadField, ReferenceEqual and CheckIf, which work automatically with the EscapeAnalysis and the BranchConditionElimination. Bug: v8:6702 Change-Id: I91235413eea478ba77ace7bd14bb2f62e155dd9a Reviewed-on: https://chromium-review.googlesource.com/645949 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#47768}
2017-09-01 10:49:06 +00:00
.ForInPrepare(triple, feedback_slot)
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
.CallRuntime(Runtime::kLoadIC_Miss, reg_0)
.Debugger()
.Return();
[ignition] Remove handles from bytecode generation Removes handles from bytecode generation, instead storing un-internalized AstValues (and other, similar values such as Scopes and AstRawStrings) in the constant array builder. This will allow us in the future to generate the bytecode before internalizing the AST. BUG=v8:5832 Change-Id: I3b8be8f7329a484eb1e5d12808b001d3475239da Reviewed-on: https://chromium-review.googlesource.com/439326 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#43115}
2017-02-10 17:22:45 +00:00
ast_factory.Internalize(isolate());
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
Handle<BytecodeArray> bytecodeArray = builder.ToBytecodeArray(isolate());
BytecodeArrayRandomIterator iterator(bytecodeArray, zone());
iterator.GoToStart();
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kLdaConstant);
EXPECT_EQ(iterator.current_index(), 0);
EXPECT_EQ(iterator.current_offset(), 0);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
[ast] Move AstValue implementation into Literal This eliminates the AstValue class, effectively moving its implementation into the Literal AstNode. This should cause no difference in behavior, but it does signal some shifts in the underlying system. Biggest changes include: - Reduction in AST memory usage - No duplicate HeapNumbers in Ignition constant pools - Non-String values are allocated either at constant pool creation time (or at boilerplate creation time for literals), rather than at AstValueFactory::Internalize() time. There are a variety of test-only/debug-only changes due to these switches as well. Bug: v8:6984 Change-Id: I5f178040ce2796d4e7370c24d1063419e1c843a1 Reviewed-on: https://chromium-review.googlesource.com/731111 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#49013}
2017-10-27 19:53:15 +00:00
EXPECT_EQ(iterator.GetConstantForIndexOperand(0)->Number(), heap_num_0);
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
ASSERT_TRUE(iterator.IsValid());
}
TEST_F(BytecodeArrayRandomIteratorTest, AccessesLast) {
// Use a builder to create an array with containing multiple bytecodes
// with 0, 1 and 2 operands.
[Cleanup][Interpreter] Move feedback slot allocation to bytecode generator Moves the feedback vector slot allocation out of ast-numbering and into bytecode generation directly. This has a couple of benifits, including reduced AST size, avoid code duplication and reduced feedback vector sizes in many cases due to only allocating slots when needed. Also removes AstProperties since this is no longer needed. AstNumbering is now only used to allocate suspend ids for generators. BUG=v8:6921 Change-Id: I103e8593c94ef5b2e56c34ef4f77bd6e7d64796f Reviewed-on: https://chromium-review.googlesource.com/722959 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48757}
2017-10-19 15:12:42 +00:00
FeedbackVectorSpec feedback_spec(zone());
[Compiler] Remove isolate from CompilationInfo. Removes Isolate from compilation info and instead threads isolate through function calls. This ensures that we can't access the isolate from background thread compilations. BUG=v8:5203 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I9a4e1cd67c4736e36f609360b996fb55166a1c50 Reviewed-on: https://chromium-review.googlesource.com/751745 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#49386}
2017-11-15 14:36:57 +00:00
BytecodeArrayBuilder builder(zone(), 3, 3, &feedback_spec);
[ignition] Remove handles from bytecode generation Removes handles from bytecode generation, instead storing un-internalized AstValues (and other, similar values such as Scopes and AstRawStrings) in the constant array builder. This will allow us in the future to generate the bytecode before internalizing the AST. BUG=v8:5832 Change-Id: I3b8be8f7329a484eb1e5d12808b001d3475239da Reviewed-on: https://chromium-review.googlesource.com/439326 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#43115}
2017-02-10 17:22:45 +00:00
AstValueFactory ast_factory(zone(), isolate()->ast_string_constants(),
isolate()->heap()->HashSeed());
[ast] Move AstValue implementation into Literal This eliminates the AstValue class, effectively moving its implementation into the Literal AstNode. This should cause no difference in behavior, but it does signal some shifts in the underlying system. Biggest changes include: - Reduction in AST memory usage - No duplicate HeapNumbers in Ignition constant pools - Non-String values are allocated either at constant pool creation time (or at boilerplate creation time for literals), rather than at AstValueFactory::Internalize() time. There are a variety of test-only/debug-only changes due to these switches as well. Bug: v8:6984 Change-Id: I5f178040ce2796d4e7370c24d1063419e1c843a1 Reviewed-on: https://chromium-review.googlesource.com/731111 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#49013}
2017-10-27 19:53:15 +00:00
double heap_num_0 = 2.718;
double heap_num_1 = 2.0 * Smi::kMaxValue;
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
Smi* zero = Smi::kZero;
Smi* smi_0 = Smi::FromInt(64);
Smi* smi_1 = Smi::FromInt(-65536);
Register reg_0(0);
Register reg_1(1);
RegisterList pair(0, 2);
RegisterList triple(0, 3);
Register param = Register::FromParameterIndex(2, builder.parameter_count());
[ignition] Remove handles from bytecode generation Removes handles from bytecode generation, instead storing un-internalized AstValues (and other, similar values such as Scopes and AstRawStrings) in the constant array builder. This will allow us in the future to generate the bytecode before internalizing the AST. BUG=v8:5832 Change-Id: I3b8be8f7329a484eb1e5d12808b001d3475239da Reviewed-on: https://chromium-review.googlesource.com/439326 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#43115}
2017-02-10 17:22:45 +00:00
const AstRawString* name = ast_factory.GetOneByteString("abc");
[Cleanup][Interpreter] Move feedback slot allocation to bytecode generator Moves the feedback vector slot allocation out of ast-numbering and into bytecode generation directly. This has a couple of benifits, including reduced AST size, avoid code duplication and reduced feedback vector sizes in many cases due to only allocating slots when needed. Also removes AstProperties since this is no longer needed. AstNumbering is now only used to allocate suspend ids for generators. BUG=v8:6921 Change-Id: I103e8593c94ef5b2e56c34ef4f77bd6e7d64796f Reviewed-on: https://chromium-review.googlesource.com/722959 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48757}
2017-10-19 15:12:42 +00:00
uint32_t feedback_slot = feedback_spec.AddLoadICSlot().ToInt();
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
builder.LoadLiteral(heap_num_0)
.StoreAccumulatorInRegister(reg_0)
.LoadLiteral(heap_num_1)
.StoreAccumulatorInRegister(reg_0)
.LoadLiteral(zero)
.StoreAccumulatorInRegister(reg_0)
.LoadLiteral(smi_0)
.StackCheck(0)
.StoreAccumulatorInRegister(reg_0)
.LoadLiteral(smi_1)
.StackCheck(1)
.StoreAccumulatorInRegister(reg_1)
.LoadAccumulatorWithRegister(reg_0)
.BinaryOperation(Token::Value::ADD, reg_0, 2)
.StoreAccumulatorInRegister(reg_1)
.LoadNamedProperty(reg_1, name, feedback_slot)
.BinaryOperation(Token::Value::ADD, reg_0, 3)
.StoreAccumulatorInRegister(param)
.CallRuntimeForPair(Runtime::kLoadLookupSlotForCall, param, pair)
[turbofan] Optimize fast enum cache driven for..in. This CL adds support to optimize for..in in fast enum-cache mode to the same degree that it was optimized in Crankshaft, without adding the same deoptimization loop that Crankshaft had with missing enum cache indices. That means code like for (var k in o) { var v = o[k]; // ... } and code like for (var k in o) { if (Object.prototype.hasOwnProperty.call(o, k)) { var v = o[k]; // ... } } which follows the https://eslint.org/docs/rules/guard-for-in linter rule, can now utilize the enum cache indices if o has only fast properties on the receiver, which speeds up the access o[k] significantly and reduces the pollution of the global megamorphic stub cache. For example the micro-benchmark in the tracking bug v8:6702 now runs faster than ever before: forIn: 1516 ms. forInHasOwnProperty: 1674 ms. forInHasOwnPropertySafe: 1595 ms. forInSum: 2051 ms. forInSumSafe: 2215 ms. Compared to numbers from V8 5.8 which is the last version running with Crankshaft forIn: 1641 ms. forInHasOwnProperty: 1719 ms. forInHasOwnPropertySafe: 1802 ms. forInSum: 2226 ms. forInSumSafe: 2409 ms. and V8 6.0 which is the current stable version with TurboFan: forIn: 1713 ms. forInHasOwnProperty: 5417 ms. forInHasOwnPropertySafe: 5324 ms. forInSum: 7556 ms. forInSumSafe: 11067 ms. It also improves the throughput on the string-fasta benchmark by around 7-10%, and there seems to be a ~5% improvement on the Speedometer/React benchmark locally. For this to work, the ForInPrepare bytecode was split into ForInEnumerate and ForInPrepare, which is very similar to how it was handled in Fullcodegen initially. In TurboFan we introduce a new operator LoadFieldByIndex that does the dynamic property load. This also removes the CheckMapValue operator again in favor of just using LoadField, ReferenceEqual and CheckIf, which work automatically with the EscapeAnalysis and the BranchConditionElimination. Bug: v8:6702 Change-Id: I91235413eea478ba77ace7bd14bb2f62e155dd9a Reviewed-on: https://chromium-review.googlesource.com/645949 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#47768}
2017-09-01 10:49:06 +00:00
.ForInPrepare(triple, feedback_slot)
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
.CallRuntime(Runtime::kLoadIC_Miss, reg_0)
.Debugger()
.Return();
[ignition] Remove handles from bytecode generation Removes handles from bytecode generation, instead storing un-internalized AstValues (and other, similar values such as Scopes and AstRawStrings) in the constant array builder. This will allow us in the future to generate the bytecode before internalizing the AST. BUG=v8:5832 Change-Id: I3b8be8f7329a484eb1e5d12808b001d3475239da Reviewed-on: https://chromium-review.googlesource.com/439326 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#43115}
2017-02-10 17:22:45 +00:00
ast_factory.Internalize(isolate());
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
Handle<BytecodeArray> bytecodeArray = builder.ToBytecodeArray(isolate());
BytecodeArrayRandomIterator iterator(bytecodeArray, zone());
iterator.GoToEnd();
int offset = bytecodeArray->length() -
Bytecodes::Size(Bytecode::kReturn, OperandScale::kSingle);
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kReturn);
[Cleanup][Interpreter] Move feedback slot allocation to bytecode generator Moves the feedback vector slot allocation out of ast-numbering and into bytecode generation directly. This has a couple of benifits, including reduced AST size, avoid code duplication and reduced feedback vector sizes in many cases due to only allocating slots when needed. Also removes AstProperties since this is no longer needed. AstNumbering is now only used to allocate suspend ids for generators. BUG=v8:6921 Change-Id: I103e8593c94ef5b2e56c34ef4f77bd6e7d64796f Reviewed-on: https://chromium-review.googlesource.com/722959 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48757}
2017-10-19 15:12:42 +00:00
EXPECT_EQ(iterator.current_index(), 22);
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
ASSERT_TRUE(iterator.IsValid());
}
TEST_F(BytecodeArrayRandomIteratorTest, RandomAccessValid) {
// Use a builder to create an array with containing multiple bytecodes
// with 0, 1 and 2 operands.
[Cleanup][Interpreter] Move feedback slot allocation to bytecode generator Moves the feedback vector slot allocation out of ast-numbering and into bytecode generation directly. This has a couple of benifits, including reduced AST size, avoid code duplication and reduced feedback vector sizes in many cases due to only allocating slots when needed. Also removes AstProperties since this is no longer needed. AstNumbering is now only used to allocate suspend ids for generators. BUG=v8:6921 Change-Id: I103e8593c94ef5b2e56c34ef4f77bd6e7d64796f Reviewed-on: https://chromium-review.googlesource.com/722959 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48757}
2017-10-19 15:12:42 +00:00
FeedbackVectorSpec feedback_spec(zone());
[Compiler] Remove isolate from CompilationInfo. Removes Isolate from compilation info and instead threads isolate through function calls. This ensures that we can't access the isolate from background thread compilations. BUG=v8:5203 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I9a4e1cd67c4736e36f609360b996fb55166a1c50 Reviewed-on: https://chromium-review.googlesource.com/751745 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#49386}
2017-11-15 14:36:57 +00:00
BytecodeArrayBuilder builder(zone(), 3, 3, &feedback_spec);
[ignition] Remove handles from bytecode generation Removes handles from bytecode generation, instead storing un-internalized AstValues (and other, similar values such as Scopes and AstRawStrings) in the constant array builder. This will allow us in the future to generate the bytecode before internalizing the AST. BUG=v8:5832 Change-Id: I3b8be8f7329a484eb1e5d12808b001d3475239da Reviewed-on: https://chromium-review.googlesource.com/439326 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#43115}
2017-02-10 17:22:45 +00:00
AstValueFactory ast_factory(zone(), isolate()->ast_string_constants(),
isolate()->heap()->HashSeed());
[ast] Move AstValue implementation into Literal This eliminates the AstValue class, effectively moving its implementation into the Literal AstNode. This should cause no difference in behavior, but it does signal some shifts in the underlying system. Biggest changes include: - Reduction in AST memory usage - No duplicate HeapNumbers in Ignition constant pools - Non-String values are allocated either at constant pool creation time (or at boilerplate creation time for literals), rather than at AstValueFactory::Internalize() time. There are a variety of test-only/debug-only changes due to these switches as well. Bug: v8:6984 Change-Id: I5f178040ce2796d4e7370c24d1063419e1c843a1 Reviewed-on: https://chromium-review.googlesource.com/731111 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#49013}
2017-10-27 19:53:15 +00:00
double heap_num_0 = 2.718;
double heap_num_1 = 2.0 * Smi::kMaxValue;
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
Smi* zero = Smi::kZero;
Smi* smi_0 = Smi::FromInt(64);
Smi* smi_1 = Smi::FromInt(-65536);
Register reg_0(0);
Register reg_1(1);
RegisterList pair(0, 2);
RegisterList triple(0, 3);
Register param = Register::FromParameterIndex(2, builder.parameter_count());
[ignition] Remove handles from bytecode generation Removes handles from bytecode generation, instead storing un-internalized AstValues (and other, similar values such as Scopes and AstRawStrings) in the constant array builder. This will allow us in the future to generate the bytecode before internalizing the AST. BUG=v8:5832 Change-Id: I3b8be8f7329a484eb1e5d12808b001d3475239da Reviewed-on: https://chromium-review.googlesource.com/439326 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#43115}
2017-02-10 17:22:45 +00:00
const AstRawString* name = ast_factory.GetOneByteString("abc");
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
uint32_t name_index = 2;
[Cleanup][Interpreter] Move feedback slot allocation to bytecode generator Moves the feedback vector slot allocation out of ast-numbering and into bytecode generation directly. This has a couple of benifits, including reduced AST size, avoid code duplication and reduced feedback vector sizes in many cases due to only allocating slots when needed. Also removes AstProperties since this is no longer needed. AstNumbering is now only used to allocate suspend ids for generators. BUG=v8:6921 Change-Id: I103e8593c94ef5b2e56c34ef4f77bd6e7d64796f Reviewed-on: https://chromium-review.googlesource.com/722959 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48757}
2017-10-19 15:12:42 +00:00
uint32_t feedback_slot = feedback_spec.AddLoadICSlot().ToInt();
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
builder.LoadLiteral(heap_num_0)
.StoreAccumulatorInRegister(reg_0)
.LoadLiteral(heap_num_1)
.StoreAccumulatorInRegister(reg_0)
.LoadLiteral(zero)
.StoreAccumulatorInRegister(reg_0)
.LoadLiteral(smi_0)
.StackCheck(0)
.StoreAccumulatorInRegister(reg_0)
.LoadLiteral(smi_1)
.StackCheck(1)
.StoreAccumulatorInRegister(reg_1)
.LoadAccumulatorWithRegister(reg_0)
.BinaryOperation(Token::Value::ADD, reg_0, 2)
.StoreAccumulatorInRegister(reg_1)
.LoadNamedProperty(reg_1, name, feedback_slot)
.BinaryOperation(Token::Value::ADD, reg_0, 3)
.StoreAccumulatorInRegister(param)
.CallRuntimeForPair(Runtime::kLoadLookupSlotForCall, param, pair)
[turbofan] Optimize fast enum cache driven for..in. This CL adds support to optimize for..in in fast enum-cache mode to the same degree that it was optimized in Crankshaft, without adding the same deoptimization loop that Crankshaft had with missing enum cache indices. That means code like for (var k in o) { var v = o[k]; // ... } and code like for (var k in o) { if (Object.prototype.hasOwnProperty.call(o, k)) { var v = o[k]; // ... } } which follows the https://eslint.org/docs/rules/guard-for-in linter rule, can now utilize the enum cache indices if o has only fast properties on the receiver, which speeds up the access o[k] significantly and reduces the pollution of the global megamorphic stub cache. For example the micro-benchmark in the tracking bug v8:6702 now runs faster than ever before: forIn: 1516 ms. forInHasOwnProperty: 1674 ms. forInHasOwnPropertySafe: 1595 ms. forInSum: 2051 ms. forInSumSafe: 2215 ms. Compared to numbers from V8 5.8 which is the last version running with Crankshaft forIn: 1641 ms. forInHasOwnProperty: 1719 ms. forInHasOwnPropertySafe: 1802 ms. forInSum: 2226 ms. forInSumSafe: 2409 ms. and V8 6.0 which is the current stable version with TurboFan: forIn: 1713 ms. forInHasOwnProperty: 5417 ms. forInHasOwnPropertySafe: 5324 ms. forInSum: 7556 ms. forInSumSafe: 11067 ms. It also improves the throughput on the string-fasta benchmark by around 7-10%, and there seems to be a ~5% improvement on the Speedometer/React benchmark locally. For this to work, the ForInPrepare bytecode was split into ForInEnumerate and ForInPrepare, which is very similar to how it was handled in Fullcodegen initially. In TurboFan we introduce a new operator LoadFieldByIndex that does the dynamic property load. This also removes the CheckMapValue operator again in favor of just using LoadField, ReferenceEqual and CheckIf, which work automatically with the EscapeAnalysis and the BranchConditionElimination. Bug: v8:6702 Change-Id: I91235413eea478ba77ace7bd14bb2f62e155dd9a Reviewed-on: https://chromium-review.googlesource.com/645949 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#47768}
2017-09-01 10:49:06 +00:00
.ForInPrepare(triple, feedback_slot)
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
.CallRuntime(Runtime::kLoadIC_Miss, reg_0)
.Debugger()
.Return();
// Test iterator sees the expected output from the builder.
[ignition] Remove handles from bytecode generation Removes handles from bytecode generation, instead storing un-internalized AstValues (and other, similar values such as Scopes and AstRawStrings) in the constant array builder. This will allow us in the future to generate the bytecode before internalizing the AST. BUG=v8:5832 Change-Id: I3b8be8f7329a484eb1e5d12808b001d3475239da Reviewed-on: https://chromium-review.googlesource.com/439326 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#43115}
2017-02-10 17:22:45 +00:00
ast_factory.Internalize(isolate());
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
BytecodeArrayRandomIterator iterator(builder.ToBytecodeArray(isolate()),
zone());
const int kPrefixByteSize = 1;
int offset = 0;
iterator.GoToIndex(13);
offset = Bytecodes::Size(Bytecode::kLdaConstant, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kStar, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kLdaConstant, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kStar, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kLdaZero, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kStar, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kLdaSmi, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kStackCheck, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kStar, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kLdaSmi, OperandScale::kQuadruple) +
kPrefixByteSize;
offset += Bytecodes::Size(Bytecode::kStackCheck, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kStar, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kLdar, OperandScale::kSingle);
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kAdd);
EXPECT_EQ(iterator.current_index(), 13);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(iterator.GetRegisterOperand(0).index(), reg_0.index());
EXPECT_EQ(iterator.GetRegisterOperandRange(0), 1);
ASSERT_TRUE(iterator.IsValid());
iterator.GoToIndex(2);
offset = Bytecodes::Size(Bytecode::kLdaConstant, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kStar, OperandScale::kSingle);
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kLdaConstant);
EXPECT_EQ(iterator.current_index(), 2);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
[ast] Move AstValue implementation into Literal This eliminates the AstValue class, effectively moving its implementation into the Literal AstNode. This should cause no difference in behavior, but it does signal some shifts in the underlying system. Biggest changes include: - Reduction in AST memory usage - No duplicate HeapNumbers in Ignition constant pools - Non-String values are allocated either at constant pool creation time (or at boilerplate creation time for literals), rather than at AstValueFactory::Internalize() time. There are a variety of test-only/debug-only changes due to these switches as well. Bug: v8:6984 Change-Id: I5f178040ce2796d4e7370c24d1063419e1c843a1 Reviewed-on: https://chromium-review.googlesource.com/731111 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#49013}
2017-10-27 19:53:15 +00:00
EXPECT_EQ(iterator.GetConstantForIndexOperand(0)->Number(), heap_num_1);
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
ASSERT_TRUE(iterator.IsValid());
iterator.GoToIndex(18);
offset = Bytecodes::Size(Bytecode::kLdaConstant, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kStar, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kLdaConstant, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kStar, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kLdaZero, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kStar, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kLdaSmi, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kStackCheck, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kStar, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kLdaSmi, OperandScale::kQuadruple) +
kPrefixByteSize;
offset += Bytecodes::Size(Bytecode::kStackCheck, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kStar, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kLdar, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kAdd, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kStar, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kLdaNamedProperty, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kAdd, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kStar, OperandScale::kSingle);
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kCallRuntimeForPair);
EXPECT_EQ(iterator.current_index(), 18);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(iterator.GetRuntimeIdOperand(0), Runtime::kLoadLookupSlotForCall);
EXPECT_EQ(iterator.GetRegisterOperand(1).index(), param.index());
EXPECT_EQ(iterator.GetRegisterOperandRange(1), 1);
EXPECT_EQ(iterator.GetRegisterCountOperand(2), 1u);
EXPECT_EQ(iterator.GetRegisterOperand(3).index(), reg_0.index());
EXPECT_EQ(iterator.GetRegisterOperandRange(3), 2);
ASSERT_TRUE(iterator.IsValid());
iterator -= 3;
offset -= Bytecodes::Size(Bytecode::kStar, OperandScale::kSingle);
offset -= Bytecodes::Size(Bytecode::kAdd, OperandScale::kSingle);
offset -= Bytecodes::Size(Bytecode::kLdaNamedProperty, OperandScale::kSingle);
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kLdaNamedProperty);
EXPECT_EQ(iterator.current_index(), 15);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(iterator.GetRegisterOperand(0).index(), reg_1.index());
EXPECT_EQ(iterator.GetIndexOperand(1), name_index);
EXPECT_EQ(iterator.GetIndexOperand(2), feedback_slot);
ASSERT_TRUE(iterator.IsValid());
iterator += 2;
offset += Bytecodes::Size(Bytecode::kLdaNamedProperty, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kAdd, OperandScale::kSingle);
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kStar);
EXPECT_EQ(iterator.current_index(), 17);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(iterator.GetRegisterOperand(0).index(), param.index());
EXPECT_EQ(iterator.GetRegisterOperandRange(0), 1);
ASSERT_TRUE(iterator.IsValid());
[Cleanup][Interpreter] Move feedback slot allocation to bytecode generator Moves the feedback vector slot allocation out of ast-numbering and into bytecode generation directly. This has a couple of benifits, including reduced AST size, avoid code duplication and reduced feedback vector sizes in many cases due to only allocating slots when needed. Also removes AstProperties since this is no longer needed. AstNumbering is now only used to allocate suspend ids for generators. BUG=v8:6921 Change-Id: I103e8593c94ef5b2e56c34ef4f77bd6e7d64796f Reviewed-on: https://chromium-review.googlesource.com/722959 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48757}
2017-10-19 15:12:42 +00:00
iterator.GoToIndex(22);
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
offset = Bytecodes::Size(Bytecode::kLdaConstant, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kStar, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kLdaConstant, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kStar, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kLdaZero, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kStar, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kLdaSmi, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kStackCheck, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kStar, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kLdaSmi, OperandScale::kQuadruple) +
kPrefixByteSize;
offset += Bytecodes::Size(Bytecode::kStackCheck, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kStar, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kLdar, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kAdd, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kStar, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kLdaNamedProperty, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kAdd, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kStar, OperandScale::kSingle);
offset +=
Bytecodes::Size(Bytecode::kCallRuntimeForPair, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kForInPrepare, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kCallRuntime, OperandScale::kSingle);
offset += Bytecodes::Size(Bytecode::kDebugger, OperandScale::kSingle);
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kReturn);
[Cleanup][Interpreter] Move feedback slot allocation to bytecode generator Moves the feedback vector slot allocation out of ast-numbering and into bytecode generation directly. This has a couple of benifits, including reduced AST size, avoid code duplication and reduced feedback vector sizes in many cases due to only allocating slots when needed. Also removes AstProperties since this is no longer needed. AstNumbering is now only used to allocate suspend ids for generators. BUG=v8:6921 Change-Id: I103e8593c94ef5b2e56c34ef4f77bd6e7d64796f Reviewed-on: https://chromium-review.googlesource.com/722959 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48757}
2017-10-19 15:12:42 +00:00
EXPECT_EQ(iterator.current_index(), 22);
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
ASSERT_TRUE(iterator.IsValid());
iterator.GoToIndex(24);
EXPECT_FALSE(iterator.IsValid());
iterator.GoToIndex(-5);
EXPECT_FALSE(iterator.IsValid());
}
TEST_F(BytecodeArrayRandomIteratorTest, IteratesBytecodeArray) {
// Use a builder to create an array with containing multiple bytecodes
// with 0, 1 and 2 operands.
[Cleanup][Interpreter] Move feedback slot allocation to bytecode generator Moves the feedback vector slot allocation out of ast-numbering and into bytecode generation directly. This has a couple of benifits, including reduced AST size, avoid code duplication and reduced feedback vector sizes in many cases due to only allocating slots when needed. Also removes AstProperties since this is no longer needed. AstNumbering is now only used to allocate suspend ids for generators. BUG=v8:6921 Change-Id: I103e8593c94ef5b2e56c34ef4f77bd6e7d64796f Reviewed-on: https://chromium-review.googlesource.com/722959 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48757}
2017-10-19 15:12:42 +00:00
FeedbackVectorSpec feedback_spec(zone());
[Compiler] Remove isolate from CompilationInfo. Removes Isolate from compilation info and instead threads isolate through function calls. This ensures that we can't access the isolate from background thread compilations. BUG=v8:5203 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I9a4e1cd67c4736e36f609360b996fb55166a1c50 Reviewed-on: https://chromium-review.googlesource.com/751745 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#49386}
2017-11-15 14:36:57 +00:00
BytecodeArrayBuilder builder(zone(), 3, 3, &feedback_spec);
[ignition] Remove handles from bytecode generation Removes handles from bytecode generation, instead storing un-internalized AstValues (and other, similar values such as Scopes and AstRawStrings) in the constant array builder. This will allow us in the future to generate the bytecode before internalizing the AST. BUG=v8:5832 Change-Id: I3b8be8f7329a484eb1e5d12808b001d3475239da Reviewed-on: https://chromium-review.googlesource.com/439326 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#43115}
2017-02-10 17:22:45 +00:00
AstValueFactory ast_factory(zone(), isolate()->ast_string_constants(),
isolate()->heap()->HashSeed());
[ast] Move AstValue implementation into Literal This eliminates the AstValue class, effectively moving its implementation into the Literal AstNode. This should cause no difference in behavior, but it does signal some shifts in the underlying system. Biggest changes include: - Reduction in AST memory usage - No duplicate HeapNumbers in Ignition constant pools - Non-String values are allocated either at constant pool creation time (or at boilerplate creation time for literals), rather than at AstValueFactory::Internalize() time. There are a variety of test-only/debug-only changes due to these switches as well. Bug: v8:6984 Change-Id: I5f178040ce2796d4e7370c24d1063419e1c843a1 Reviewed-on: https://chromium-review.googlesource.com/731111 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#49013}
2017-10-27 19:53:15 +00:00
double heap_num_0 = 2.718;
double heap_num_1 = 2.0 * Smi::kMaxValue;
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
Smi* zero = Smi::kZero;
Smi* smi_0 = Smi::FromInt(64);
Smi* smi_1 = Smi::FromInt(-65536);
Register reg_0(0);
Register reg_1(1);
RegisterList pair(0, 2);
RegisterList triple(0, 3);
Register param = Register::FromParameterIndex(2, builder.parameter_count());
[ignition] Remove handles from bytecode generation Removes handles from bytecode generation, instead storing un-internalized AstValues (and other, similar values such as Scopes and AstRawStrings) in the constant array builder. This will allow us in the future to generate the bytecode before internalizing the AST. BUG=v8:5832 Change-Id: I3b8be8f7329a484eb1e5d12808b001d3475239da Reviewed-on: https://chromium-review.googlesource.com/439326 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#43115}
2017-02-10 17:22:45 +00:00
const AstRawString* name = ast_factory.GetOneByteString("abc");
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
uint32_t name_index = 2;
[Cleanup][Interpreter] Move feedback slot allocation to bytecode generator Moves the feedback vector slot allocation out of ast-numbering and into bytecode generation directly. This has a couple of benifits, including reduced AST size, avoid code duplication and reduced feedback vector sizes in many cases due to only allocating slots when needed. Also removes AstProperties since this is no longer needed. AstNumbering is now only used to allocate suspend ids for generators. BUG=v8:6921 Change-Id: I103e8593c94ef5b2e56c34ef4f77bd6e7d64796f Reviewed-on: https://chromium-review.googlesource.com/722959 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48757}
2017-10-19 15:12:42 +00:00
uint32_t feedback_slot = feedback_spec.AddLoadICSlot().ToInt();
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
builder.LoadLiteral(heap_num_0)
.StoreAccumulatorInRegister(reg_0)
.LoadLiteral(heap_num_1)
.StoreAccumulatorInRegister(reg_0)
.LoadLiteral(zero)
.StoreAccumulatorInRegister(reg_0)
.LoadLiteral(smi_0)
.StackCheck(0)
.StoreAccumulatorInRegister(reg_0)
.LoadLiteral(smi_1)
.StackCheck(1)
.StoreAccumulatorInRegister(reg_1)
.LoadAccumulatorWithRegister(reg_0)
.BinaryOperation(Token::Value::ADD, reg_0, 2)
.StoreAccumulatorInRegister(reg_1)
.LoadNamedProperty(reg_1, name, feedback_slot)
.BinaryOperation(Token::Value::ADD, reg_0, 3)
.StoreAccumulatorInRegister(param)
.CallRuntimeForPair(Runtime::kLoadLookupSlotForCall, param, pair)
[turbofan] Optimize fast enum cache driven for..in. This CL adds support to optimize for..in in fast enum-cache mode to the same degree that it was optimized in Crankshaft, without adding the same deoptimization loop that Crankshaft had with missing enum cache indices. That means code like for (var k in o) { var v = o[k]; // ... } and code like for (var k in o) { if (Object.prototype.hasOwnProperty.call(o, k)) { var v = o[k]; // ... } } which follows the https://eslint.org/docs/rules/guard-for-in linter rule, can now utilize the enum cache indices if o has only fast properties on the receiver, which speeds up the access o[k] significantly and reduces the pollution of the global megamorphic stub cache. For example the micro-benchmark in the tracking bug v8:6702 now runs faster than ever before: forIn: 1516 ms. forInHasOwnProperty: 1674 ms. forInHasOwnPropertySafe: 1595 ms. forInSum: 2051 ms. forInSumSafe: 2215 ms. Compared to numbers from V8 5.8 which is the last version running with Crankshaft forIn: 1641 ms. forInHasOwnProperty: 1719 ms. forInHasOwnPropertySafe: 1802 ms. forInSum: 2226 ms. forInSumSafe: 2409 ms. and V8 6.0 which is the current stable version with TurboFan: forIn: 1713 ms. forInHasOwnProperty: 5417 ms. forInHasOwnPropertySafe: 5324 ms. forInSum: 7556 ms. forInSumSafe: 11067 ms. It also improves the throughput on the string-fasta benchmark by around 7-10%, and there seems to be a ~5% improvement on the Speedometer/React benchmark locally. For this to work, the ForInPrepare bytecode was split into ForInEnumerate and ForInPrepare, which is very similar to how it was handled in Fullcodegen initially. In TurboFan we introduce a new operator LoadFieldByIndex that does the dynamic property load. This also removes the CheckMapValue operator again in favor of just using LoadField, ReferenceEqual and CheckIf, which work automatically with the EscapeAnalysis and the BranchConditionElimination. Bug: v8:6702 Change-Id: I91235413eea478ba77ace7bd14bb2f62e155dd9a Reviewed-on: https://chromium-review.googlesource.com/645949 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#47768}
2017-09-01 10:49:06 +00:00
.ForInPrepare(triple, feedback_slot)
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
.CallRuntime(Runtime::kLoadIC_Miss, reg_0)
.Debugger()
.Return();
// Test iterator sees the expected output from the builder.
[ignition] Remove handles from bytecode generation Removes handles from bytecode generation, instead storing un-internalized AstValues (and other, similar values such as Scopes and AstRawStrings) in the constant array builder. This will allow us in the future to generate the bytecode before internalizing the AST. BUG=v8:5832 Change-Id: I3b8be8f7329a484eb1e5d12808b001d3475239da Reviewed-on: https://chromium-review.googlesource.com/439326 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#43115}
2017-02-10 17:22:45 +00:00
ast_factory.Internalize(isolate());
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
BytecodeArrayRandomIterator iterator(builder.ToBytecodeArray(isolate()),
zone());
const int kPrefixByteSize = 1;
int offset = 0;
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kLdaConstant);
EXPECT_EQ(iterator.current_index(), 0);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
[ast] Move AstValue implementation into Literal This eliminates the AstValue class, effectively moving its implementation into the Literal AstNode. This should cause no difference in behavior, but it does signal some shifts in the underlying system. Biggest changes include: - Reduction in AST memory usage - No duplicate HeapNumbers in Ignition constant pools - Non-String values are allocated either at constant pool creation time (or at boilerplate creation time for literals), rather than at AstValueFactory::Internalize() time. There are a variety of test-only/debug-only changes due to these switches as well. Bug: v8:6984 Change-Id: I5f178040ce2796d4e7370c24d1063419e1c843a1 Reviewed-on: https://chromium-review.googlesource.com/731111 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#49013}
2017-10-27 19:53:15 +00:00
EXPECT_EQ(iterator.GetConstantForIndexOperand(0)->Number(), heap_num_0);
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
ASSERT_TRUE(iterator.IsValid());
offset += Bytecodes::Size(Bytecode::kLdaConstant, OperandScale::kSingle);
++iterator;
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kStar);
EXPECT_EQ(iterator.current_index(), 1);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(iterator.GetRegisterOperand(0).index(), reg_0.index());
EXPECT_EQ(iterator.GetRegisterOperandRange(0), 1);
ASSERT_TRUE(iterator.IsValid());
offset += Bytecodes::Size(Bytecode::kStar, OperandScale::kSingle);
++iterator;
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kLdaConstant);
EXPECT_EQ(iterator.current_index(), 2);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
[ast] Move AstValue implementation into Literal This eliminates the AstValue class, effectively moving its implementation into the Literal AstNode. This should cause no difference in behavior, but it does signal some shifts in the underlying system. Biggest changes include: - Reduction in AST memory usage - No duplicate HeapNumbers in Ignition constant pools - Non-String values are allocated either at constant pool creation time (or at boilerplate creation time for literals), rather than at AstValueFactory::Internalize() time. There are a variety of test-only/debug-only changes due to these switches as well. Bug: v8:6984 Change-Id: I5f178040ce2796d4e7370c24d1063419e1c843a1 Reviewed-on: https://chromium-review.googlesource.com/731111 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#49013}
2017-10-27 19:53:15 +00:00
EXPECT_EQ(iterator.GetConstantForIndexOperand(0)->Number(), heap_num_1);
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
ASSERT_TRUE(iterator.IsValid());
offset += Bytecodes::Size(Bytecode::kLdaConstant, OperandScale::kSingle);
++iterator;
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kStar);
EXPECT_EQ(iterator.current_index(), 3);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(iterator.GetRegisterOperand(0).index(), reg_0.index());
EXPECT_EQ(iterator.GetRegisterOperandRange(0), 1);
ASSERT_TRUE(iterator.IsValid());
offset += Bytecodes::Size(Bytecode::kStar, OperandScale::kSingle);
++iterator;
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kLdaZero);
EXPECT_EQ(iterator.current_index(), 4);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
ASSERT_TRUE(iterator.IsValid());
offset += Bytecodes::Size(Bytecode::kLdaZero, OperandScale::kSingle);
++iterator;
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kStar);
EXPECT_EQ(iterator.current_index(), 5);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(iterator.GetRegisterOperand(0).index(), reg_0.index());
EXPECT_EQ(iterator.GetRegisterOperandRange(0), 1);
ASSERT_TRUE(iterator.IsValid());
offset += Bytecodes::Size(Bytecode::kStar, OperandScale::kSingle);
++iterator;
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kLdaSmi);
EXPECT_EQ(iterator.current_index(), 6);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(Smi::FromInt(iterator.GetImmediateOperand(0)), smi_0);
ASSERT_TRUE(iterator.IsValid());
offset += Bytecodes::Size(Bytecode::kLdaSmi, OperandScale::kSingle);
++iterator;
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kStackCheck);
EXPECT_EQ(iterator.current_index(), 7);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(Bytecodes::NumberOfOperands(iterator.current_bytecode()), 0);
ASSERT_TRUE(iterator.IsValid());
offset += Bytecodes::Size(Bytecode::kStackCheck, OperandScale::kSingle);
++iterator;
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kStar);
EXPECT_EQ(iterator.current_index(), 8);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(iterator.GetRegisterOperand(0).index(), reg_0.index());
EXPECT_EQ(iterator.GetRegisterOperandRange(0), 1);
ASSERT_TRUE(iterator.IsValid());
offset += Bytecodes::Size(Bytecode::kStar, OperandScale::kSingle);
++iterator;
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kLdaSmi);
EXPECT_EQ(iterator.current_index(), 9);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kQuadruple);
EXPECT_EQ(Smi::FromInt(iterator.GetImmediateOperand(0)), smi_1);
ASSERT_TRUE(iterator.IsValid());
offset += Bytecodes::Size(Bytecode::kLdaSmi, OperandScale::kQuadruple) +
kPrefixByteSize;
++iterator;
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kStackCheck);
EXPECT_EQ(iterator.current_index(), 10);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(Bytecodes::NumberOfOperands(iterator.current_bytecode()), 0);
ASSERT_TRUE(iterator.IsValid());
offset += Bytecodes::Size(Bytecode::kStackCheck, OperandScale::kSingle);
++iterator;
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kStar);
EXPECT_EQ(iterator.current_index(), 11);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(iterator.GetRegisterOperand(0).index(), reg_1.index());
EXPECT_EQ(iterator.GetRegisterOperandRange(0), 1);
ASSERT_TRUE(iterator.IsValid());
offset += Bytecodes::Size(Bytecode::kStar, OperandScale::kSingle);
++iterator;
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kLdar);
EXPECT_EQ(iterator.current_index(), 12);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(iterator.GetRegisterOperand(0).index(), reg_0.index());
ASSERT_TRUE(iterator.IsValid());
offset += Bytecodes::Size(Bytecode::kLdar, OperandScale::kSingle);
++iterator;
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kAdd);
EXPECT_EQ(iterator.current_index(), 13);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(iterator.GetRegisterOperand(0).index(), reg_0.index());
EXPECT_EQ(iterator.GetRegisterOperandRange(0), 1);
ASSERT_TRUE(iterator.IsValid());
offset += Bytecodes::Size(Bytecode::kAdd, OperandScale::kSingle);
++iterator;
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kStar);
EXPECT_EQ(iterator.current_index(), 14);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(iterator.GetRegisterOperand(0).index(), reg_1.index());
EXPECT_EQ(iterator.GetRegisterOperandRange(0), 1);
ASSERT_TRUE(iterator.IsValid());
offset += Bytecodes::Size(Bytecode::kStar, OperandScale::kSingle);
++iterator;
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kLdaNamedProperty);
EXPECT_EQ(iterator.current_index(), 15);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(iterator.GetRegisterOperand(0).index(), reg_1.index());
EXPECT_EQ(iterator.GetIndexOperand(1), name_index);
EXPECT_EQ(iterator.GetIndexOperand(2), feedback_slot);
ASSERT_TRUE(iterator.IsValid());
offset += Bytecodes::Size(Bytecode::kLdaNamedProperty, OperandScale::kSingle);
++iterator;
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kAdd);
EXPECT_EQ(iterator.current_index(), 16);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(iterator.GetRegisterOperand(0).index(), reg_0.index());
EXPECT_EQ(iterator.GetRegisterOperandRange(0), 1);
ASSERT_TRUE(iterator.IsValid());
offset += Bytecodes::Size(Bytecode::kAdd, OperandScale::kSingle);
++iterator;
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kStar);
EXPECT_EQ(iterator.current_index(), 17);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(iterator.GetRegisterOperand(0).index(), param.index());
EXPECT_EQ(iterator.GetRegisterOperandRange(0), 1);
ASSERT_TRUE(iterator.IsValid());
offset += Bytecodes::Size(Bytecode::kStar, OperandScale::kSingle);
++iterator;
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kCallRuntimeForPair);
EXPECT_EQ(iterator.current_index(), 18);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(iterator.GetRuntimeIdOperand(0), Runtime::kLoadLookupSlotForCall);
EXPECT_EQ(iterator.GetRegisterOperand(1).index(), param.index());
EXPECT_EQ(iterator.GetRegisterOperandRange(1), 1);
EXPECT_EQ(iterator.GetRegisterCountOperand(2), 1u);
EXPECT_EQ(iterator.GetRegisterOperand(3).index(), reg_0.index());
EXPECT_EQ(iterator.GetRegisterOperandRange(3), 2);
ASSERT_TRUE(iterator.IsValid());
offset +=
Bytecodes::Size(Bytecode::kCallRuntimeForPair, OperandScale::kSingle);
++iterator;
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kForInPrepare);
EXPECT_EQ(iterator.current_index(), 19);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(iterator.GetRegisterOperand(0).index(), reg_0.index());
[turbofan] Optimize fast enum cache driven for..in. This CL adds support to optimize for..in in fast enum-cache mode to the same degree that it was optimized in Crankshaft, without adding the same deoptimization loop that Crankshaft had with missing enum cache indices. That means code like for (var k in o) { var v = o[k]; // ... } and code like for (var k in o) { if (Object.prototype.hasOwnProperty.call(o, k)) { var v = o[k]; // ... } } which follows the https://eslint.org/docs/rules/guard-for-in linter rule, can now utilize the enum cache indices if o has only fast properties on the receiver, which speeds up the access o[k] significantly and reduces the pollution of the global megamorphic stub cache. For example the micro-benchmark in the tracking bug v8:6702 now runs faster than ever before: forIn: 1516 ms. forInHasOwnProperty: 1674 ms. forInHasOwnPropertySafe: 1595 ms. forInSum: 2051 ms. forInSumSafe: 2215 ms. Compared to numbers from V8 5.8 which is the last version running with Crankshaft forIn: 1641 ms. forInHasOwnProperty: 1719 ms. forInHasOwnPropertySafe: 1802 ms. forInSum: 2226 ms. forInSumSafe: 2409 ms. and V8 6.0 which is the current stable version with TurboFan: forIn: 1713 ms. forInHasOwnProperty: 5417 ms. forInHasOwnPropertySafe: 5324 ms. forInSum: 7556 ms. forInSumSafe: 11067 ms. It also improves the throughput on the string-fasta benchmark by around 7-10%, and there seems to be a ~5% improvement on the Speedometer/React benchmark locally. For this to work, the ForInPrepare bytecode was split into ForInEnumerate and ForInPrepare, which is very similar to how it was handled in Fullcodegen initially. In TurboFan we introduce a new operator LoadFieldByIndex that does the dynamic property load. This also removes the CheckMapValue operator again in favor of just using LoadField, ReferenceEqual and CheckIf, which work automatically with the EscapeAnalysis and the BranchConditionElimination. Bug: v8:6702 Change-Id: I91235413eea478ba77ace7bd14bb2f62e155dd9a Reviewed-on: https://chromium-review.googlesource.com/645949 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#47768}
2017-09-01 10:49:06 +00:00
EXPECT_EQ(iterator.GetRegisterOperandRange(0), 3);
EXPECT_EQ(iterator.GetIndexOperand(1), feedback_slot);
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
ASSERT_TRUE(iterator.IsValid());
offset += Bytecodes::Size(Bytecode::kForInPrepare, OperandScale::kSingle);
++iterator;
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kCallRuntime);
EXPECT_EQ(iterator.current_index(), 20);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(iterator.GetRuntimeIdOperand(0), Runtime::kLoadIC_Miss);
EXPECT_EQ(iterator.GetRegisterOperand(1).index(), reg_0.index());
EXPECT_EQ(iterator.GetRegisterCountOperand(2), 1u);
ASSERT_TRUE(iterator.IsValid());
offset += Bytecodes::Size(Bytecode::kCallRuntime, OperandScale::kSingle);
++iterator;
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kDebugger);
EXPECT_EQ(iterator.current_index(), 21);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
ASSERT_TRUE(iterator.IsValid());
offset += Bytecodes::Size(Bytecode::kDebugger, OperandScale::kSingle);
++iterator;
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kReturn);
[Cleanup][Interpreter] Move feedback slot allocation to bytecode generator Moves the feedback vector slot allocation out of ast-numbering and into bytecode generation directly. This has a couple of benifits, including reduced AST size, avoid code duplication and reduced feedback vector sizes in many cases due to only allocating slots when needed. Also removes AstProperties since this is no longer needed. AstNumbering is now only used to allocate suspend ids for generators. BUG=v8:6921 Change-Id: I103e8593c94ef5b2e56c34ef4f77bd6e7d64796f Reviewed-on: https://chromium-review.googlesource.com/722959 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48757}
2017-10-19 15:12:42 +00:00
EXPECT_EQ(iterator.current_index(), 22);
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
ASSERT_TRUE(iterator.IsValid());
++iterator;
ASSERT_TRUE(!iterator.IsValid());
}
TEST_F(BytecodeArrayRandomIteratorTest, IteratesBytecodeArrayBackwards) {
// Use a builder to create an array with containing multiple bytecodes
// with 0, 1 and 2 operands.
[Cleanup][Interpreter] Move feedback slot allocation to bytecode generator Moves the feedback vector slot allocation out of ast-numbering and into bytecode generation directly. This has a couple of benifits, including reduced AST size, avoid code duplication and reduced feedback vector sizes in many cases due to only allocating slots when needed. Also removes AstProperties since this is no longer needed. AstNumbering is now only used to allocate suspend ids for generators. BUG=v8:6921 Change-Id: I103e8593c94ef5b2e56c34ef4f77bd6e7d64796f Reviewed-on: https://chromium-review.googlesource.com/722959 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48757}
2017-10-19 15:12:42 +00:00
FeedbackVectorSpec feedback_spec(zone());
[Compiler] Remove isolate from CompilationInfo. Removes Isolate from compilation info and instead threads isolate through function calls. This ensures that we can't access the isolate from background thread compilations. BUG=v8:5203 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I9a4e1cd67c4736e36f609360b996fb55166a1c50 Reviewed-on: https://chromium-review.googlesource.com/751745 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#49386}
2017-11-15 14:36:57 +00:00
BytecodeArrayBuilder builder(zone(), 3, 3, &feedback_spec);
[ignition] Remove handles from bytecode generation Removes handles from bytecode generation, instead storing un-internalized AstValues (and other, similar values such as Scopes and AstRawStrings) in the constant array builder. This will allow us in the future to generate the bytecode before internalizing the AST. BUG=v8:5832 Change-Id: I3b8be8f7329a484eb1e5d12808b001d3475239da Reviewed-on: https://chromium-review.googlesource.com/439326 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#43115}
2017-02-10 17:22:45 +00:00
AstValueFactory ast_factory(zone(), isolate()->ast_string_constants(),
isolate()->heap()->HashSeed());
[ast] Move AstValue implementation into Literal This eliminates the AstValue class, effectively moving its implementation into the Literal AstNode. This should cause no difference in behavior, but it does signal some shifts in the underlying system. Biggest changes include: - Reduction in AST memory usage - No duplicate HeapNumbers in Ignition constant pools - Non-String values are allocated either at constant pool creation time (or at boilerplate creation time for literals), rather than at AstValueFactory::Internalize() time. There are a variety of test-only/debug-only changes due to these switches as well. Bug: v8:6984 Change-Id: I5f178040ce2796d4e7370c24d1063419e1c843a1 Reviewed-on: https://chromium-review.googlesource.com/731111 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#49013}
2017-10-27 19:53:15 +00:00
double heap_num_0 = 2.718;
double heap_num_1 = 2.0 * Smi::kMaxValue;
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
Smi* zero = Smi::kZero;
Smi* smi_0 = Smi::FromInt(64);
Smi* smi_1 = Smi::FromInt(-65536);
Register reg_0(0);
Register reg_1(1);
RegisterList pair(0, 2);
RegisterList triple(0, 3);
Register param = Register::FromParameterIndex(2, builder.parameter_count());
[ignition] Remove handles from bytecode generation Removes handles from bytecode generation, instead storing un-internalized AstValues (and other, similar values such as Scopes and AstRawStrings) in the constant array builder. This will allow us in the future to generate the bytecode before internalizing the AST. BUG=v8:5832 Change-Id: I3b8be8f7329a484eb1e5d12808b001d3475239da Reviewed-on: https://chromium-review.googlesource.com/439326 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#43115}
2017-02-10 17:22:45 +00:00
const AstRawString* name = ast_factory.GetOneByteString("abc");
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
uint32_t name_index = 2;
[Cleanup][Interpreter] Move feedback slot allocation to bytecode generator Moves the feedback vector slot allocation out of ast-numbering and into bytecode generation directly. This has a couple of benifits, including reduced AST size, avoid code duplication and reduced feedback vector sizes in many cases due to only allocating slots when needed. Also removes AstProperties since this is no longer needed. AstNumbering is now only used to allocate suspend ids for generators. BUG=v8:6921 Change-Id: I103e8593c94ef5b2e56c34ef4f77bd6e7d64796f Reviewed-on: https://chromium-review.googlesource.com/722959 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48757}
2017-10-19 15:12:42 +00:00
uint32_t feedback_slot = feedback_spec.AddLoadICSlot().ToInt();
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
builder.LoadLiteral(heap_num_0)
.StoreAccumulatorInRegister(reg_0)
.LoadLiteral(heap_num_1)
.StoreAccumulatorInRegister(reg_0)
.LoadLiteral(zero)
.StoreAccumulatorInRegister(reg_0)
.LoadLiteral(smi_0)
.StackCheck(0)
.StoreAccumulatorInRegister(reg_0)
.LoadLiteral(smi_1)
.StackCheck(1)
.StoreAccumulatorInRegister(reg_1)
.LoadAccumulatorWithRegister(reg_0)
.BinaryOperation(Token::Value::ADD, reg_0, 2)
.StoreAccumulatorInRegister(reg_1)
.LoadNamedProperty(reg_1, name, feedback_slot)
.BinaryOperation(Token::Value::ADD, reg_0, 3)
.StoreAccumulatorInRegister(param)
.CallRuntimeForPair(Runtime::kLoadLookupSlotForCall, param, pair)
[turbofan] Optimize fast enum cache driven for..in. This CL adds support to optimize for..in in fast enum-cache mode to the same degree that it was optimized in Crankshaft, without adding the same deoptimization loop that Crankshaft had with missing enum cache indices. That means code like for (var k in o) { var v = o[k]; // ... } and code like for (var k in o) { if (Object.prototype.hasOwnProperty.call(o, k)) { var v = o[k]; // ... } } which follows the https://eslint.org/docs/rules/guard-for-in linter rule, can now utilize the enum cache indices if o has only fast properties on the receiver, which speeds up the access o[k] significantly and reduces the pollution of the global megamorphic stub cache. For example the micro-benchmark in the tracking bug v8:6702 now runs faster than ever before: forIn: 1516 ms. forInHasOwnProperty: 1674 ms. forInHasOwnPropertySafe: 1595 ms. forInSum: 2051 ms. forInSumSafe: 2215 ms. Compared to numbers from V8 5.8 which is the last version running with Crankshaft forIn: 1641 ms. forInHasOwnProperty: 1719 ms. forInHasOwnPropertySafe: 1802 ms. forInSum: 2226 ms. forInSumSafe: 2409 ms. and V8 6.0 which is the current stable version with TurboFan: forIn: 1713 ms. forInHasOwnProperty: 5417 ms. forInHasOwnPropertySafe: 5324 ms. forInSum: 7556 ms. forInSumSafe: 11067 ms. It also improves the throughput on the string-fasta benchmark by around 7-10%, and there seems to be a ~5% improvement on the Speedometer/React benchmark locally. For this to work, the ForInPrepare bytecode was split into ForInEnumerate and ForInPrepare, which is very similar to how it was handled in Fullcodegen initially. In TurboFan we introduce a new operator LoadFieldByIndex that does the dynamic property load. This also removes the CheckMapValue operator again in favor of just using LoadField, ReferenceEqual and CheckIf, which work automatically with the EscapeAnalysis and the BranchConditionElimination. Bug: v8:6702 Change-Id: I91235413eea478ba77ace7bd14bb2f62e155dd9a Reviewed-on: https://chromium-review.googlesource.com/645949 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#47768}
2017-09-01 10:49:06 +00:00
.ForInPrepare(triple, feedback_slot)
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
.CallRuntime(Runtime::kLoadIC_Miss, reg_0)
.Debugger()
.Return();
// Test iterator sees the expected output from the builder.
[ignition] Remove handles from bytecode generation Removes handles from bytecode generation, instead storing un-internalized AstValues (and other, similar values such as Scopes and AstRawStrings) in the constant array builder. This will allow us in the future to generate the bytecode before internalizing the AST. BUG=v8:5832 Change-Id: I3b8be8f7329a484eb1e5d12808b001d3475239da Reviewed-on: https://chromium-review.googlesource.com/439326 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#43115}
2017-02-10 17:22:45 +00:00
ast_factory.Internalize(isolate());
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
Handle<BytecodeArray> bytecodeArray = builder.ToBytecodeArray(isolate());
BytecodeArrayRandomIterator iterator(bytecodeArray, zone());
const int kPrefixByteSize = 1;
int offset = bytecodeArray->length();
iterator.GoToEnd();
offset -= Bytecodes::Size(Bytecode::kReturn, OperandScale::kSingle);
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kReturn);
[Cleanup][Interpreter] Move feedback slot allocation to bytecode generator Moves the feedback vector slot allocation out of ast-numbering and into bytecode generation directly. This has a couple of benifits, including reduced AST size, avoid code duplication and reduced feedback vector sizes in many cases due to only allocating slots when needed. Also removes AstProperties since this is no longer needed. AstNumbering is now only used to allocate suspend ids for generators. BUG=v8:6921 Change-Id: I103e8593c94ef5b2e56c34ef4f77bd6e7d64796f Reviewed-on: https://chromium-review.googlesource.com/722959 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48757}
2017-10-19 15:12:42 +00:00
EXPECT_EQ(iterator.current_index(), 22);
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
ASSERT_TRUE(iterator.IsValid());
--iterator;
offset -= Bytecodes::Size(Bytecode::kDebugger, OperandScale::kSingle);
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kDebugger);
EXPECT_EQ(iterator.current_index(), 21);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
ASSERT_TRUE(iterator.IsValid());
--iterator;
offset -= Bytecodes::Size(Bytecode::kCallRuntime, OperandScale::kSingle);
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kCallRuntime);
EXPECT_EQ(iterator.current_index(), 20);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(iterator.GetRuntimeIdOperand(0), Runtime::kLoadIC_Miss);
EXPECT_EQ(iterator.GetRegisterOperand(1).index(), reg_0.index());
EXPECT_EQ(iterator.GetRegisterCountOperand(2), 1u);
ASSERT_TRUE(iterator.IsValid());
--iterator;
offset -= Bytecodes::Size(Bytecode::kForInPrepare, OperandScale::kSingle);
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kForInPrepare);
EXPECT_EQ(iterator.current_index(), 19);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(iterator.GetRegisterOperand(0).index(), reg_0.index());
[turbofan] Optimize fast enum cache driven for..in. This CL adds support to optimize for..in in fast enum-cache mode to the same degree that it was optimized in Crankshaft, without adding the same deoptimization loop that Crankshaft had with missing enum cache indices. That means code like for (var k in o) { var v = o[k]; // ... } and code like for (var k in o) { if (Object.prototype.hasOwnProperty.call(o, k)) { var v = o[k]; // ... } } which follows the https://eslint.org/docs/rules/guard-for-in linter rule, can now utilize the enum cache indices if o has only fast properties on the receiver, which speeds up the access o[k] significantly and reduces the pollution of the global megamorphic stub cache. For example the micro-benchmark in the tracking bug v8:6702 now runs faster than ever before: forIn: 1516 ms. forInHasOwnProperty: 1674 ms. forInHasOwnPropertySafe: 1595 ms. forInSum: 2051 ms. forInSumSafe: 2215 ms. Compared to numbers from V8 5.8 which is the last version running with Crankshaft forIn: 1641 ms. forInHasOwnProperty: 1719 ms. forInHasOwnPropertySafe: 1802 ms. forInSum: 2226 ms. forInSumSafe: 2409 ms. and V8 6.0 which is the current stable version with TurboFan: forIn: 1713 ms. forInHasOwnProperty: 5417 ms. forInHasOwnPropertySafe: 5324 ms. forInSum: 7556 ms. forInSumSafe: 11067 ms. It also improves the throughput on the string-fasta benchmark by around 7-10%, and there seems to be a ~5% improvement on the Speedometer/React benchmark locally. For this to work, the ForInPrepare bytecode was split into ForInEnumerate and ForInPrepare, which is very similar to how it was handled in Fullcodegen initially. In TurboFan we introduce a new operator LoadFieldByIndex that does the dynamic property load. This also removes the CheckMapValue operator again in favor of just using LoadField, ReferenceEqual and CheckIf, which work automatically with the EscapeAnalysis and the BranchConditionElimination. Bug: v8:6702 Change-Id: I91235413eea478ba77ace7bd14bb2f62e155dd9a Reviewed-on: https://chromium-review.googlesource.com/645949 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#47768}
2017-09-01 10:49:06 +00:00
EXPECT_EQ(iterator.GetRegisterOperandRange(0), 3);
EXPECT_EQ(iterator.GetIndexOperand(1), feedback_slot);
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
ASSERT_TRUE(iterator.IsValid());
--iterator;
offset -=
Bytecodes::Size(Bytecode::kCallRuntimeForPair, OperandScale::kSingle);
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kCallRuntimeForPair);
EXPECT_EQ(iterator.current_index(), 18);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(iterator.GetRuntimeIdOperand(0), Runtime::kLoadLookupSlotForCall);
EXPECT_EQ(iterator.GetRegisterOperand(1).index(), param.index());
EXPECT_EQ(iterator.GetRegisterOperandRange(1), 1);
EXPECT_EQ(iterator.GetRegisterCountOperand(2), 1u);
EXPECT_EQ(iterator.GetRegisterOperand(3).index(), reg_0.index());
EXPECT_EQ(iterator.GetRegisterOperandRange(3), 2);
ASSERT_TRUE(iterator.IsValid());
--iterator;
offset -= Bytecodes::Size(Bytecode::kStar, OperandScale::kSingle);
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kStar);
EXPECT_EQ(iterator.current_index(), 17);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(iterator.GetRegisterOperand(0).index(), param.index());
EXPECT_EQ(iterator.GetRegisterOperandRange(0), 1);
ASSERT_TRUE(iterator.IsValid());
--iterator;
offset -= Bytecodes::Size(Bytecode::kAdd, OperandScale::kSingle);
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kAdd);
EXPECT_EQ(iterator.current_index(), 16);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(iterator.GetRegisterOperand(0).index(), reg_0.index());
EXPECT_EQ(iterator.GetRegisterOperandRange(0), 1);
ASSERT_TRUE(iterator.IsValid());
--iterator;
offset -= Bytecodes::Size(Bytecode::kLdaNamedProperty, OperandScale::kSingle);
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kLdaNamedProperty);
EXPECT_EQ(iterator.current_index(), 15);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(iterator.GetRegisterOperand(0).index(), reg_1.index());
EXPECT_EQ(iterator.GetIndexOperand(1), name_index);
EXPECT_EQ(iterator.GetIndexOperand(2), feedback_slot);
ASSERT_TRUE(iterator.IsValid());
--iterator;
offset -= Bytecodes::Size(Bytecode::kStar, OperandScale::kSingle);
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kStar);
EXPECT_EQ(iterator.current_index(), 14);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(iterator.GetRegisterOperand(0).index(), reg_1.index());
EXPECT_EQ(iterator.GetRegisterOperandRange(0), 1);
ASSERT_TRUE(iterator.IsValid());
--iterator;
offset -= Bytecodes::Size(Bytecode::kAdd, OperandScale::kSingle);
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kAdd);
EXPECT_EQ(iterator.current_index(), 13);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(iterator.GetRegisterOperand(0).index(), reg_0.index());
EXPECT_EQ(iterator.GetRegisterOperandRange(0), 1);
ASSERT_TRUE(iterator.IsValid());
--iterator;
offset -= Bytecodes::Size(Bytecode::kLdar, OperandScale::kSingle);
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kLdar);
EXPECT_EQ(iterator.current_index(), 12);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(iterator.GetRegisterOperand(0).index(), reg_0.index());
ASSERT_TRUE(iterator.IsValid());
--iterator;
offset -= Bytecodes::Size(Bytecode::kStar, OperandScale::kSingle);
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kStar);
EXPECT_EQ(iterator.current_index(), 11);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(iterator.GetRegisterOperand(0).index(), reg_1.index());
EXPECT_EQ(iterator.GetRegisterOperandRange(0), 1);
ASSERT_TRUE(iterator.IsValid());
--iterator;
offset -= Bytecodes::Size(Bytecode::kStackCheck, OperandScale::kSingle);
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kStackCheck);
EXPECT_EQ(iterator.current_index(), 10);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(Bytecodes::NumberOfOperands(iterator.current_bytecode()), 0);
ASSERT_TRUE(iterator.IsValid());
--iterator;
offset -= Bytecodes::Size(Bytecode::kLdaSmi, OperandScale::kQuadruple) +
kPrefixByteSize;
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kLdaSmi);
EXPECT_EQ(iterator.current_index(), 9);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kQuadruple);
EXPECT_EQ(Smi::FromInt(iterator.GetImmediateOperand(0)), smi_1);
ASSERT_TRUE(iterator.IsValid());
--iterator;
offset -= Bytecodes::Size(Bytecode::kStar, OperandScale::kSingle);
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kStar);
EXPECT_EQ(iterator.current_index(), 8);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(iterator.GetRegisterOperand(0).index(), reg_0.index());
EXPECT_EQ(iterator.GetRegisterOperandRange(0), 1);
ASSERT_TRUE(iterator.IsValid());
--iterator;
offset -= Bytecodes::Size(Bytecode::kStackCheck, OperandScale::kSingle);
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kStackCheck);
EXPECT_EQ(iterator.current_index(), 7);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(Bytecodes::NumberOfOperands(iterator.current_bytecode()), 0);
ASSERT_TRUE(iterator.IsValid());
--iterator;
offset -= Bytecodes::Size(Bytecode::kLdaSmi, OperandScale::kSingle);
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kLdaSmi);
EXPECT_EQ(iterator.current_index(), 6);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(Smi::FromInt(iterator.GetImmediateOperand(0)), smi_0);
ASSERT_TRUE(iterator.IsValid());
--iterator;
offset -= Bytecodes::Size(Bytecode::kStar, OperandScale::kSingle);
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kStar);
EXPECT_EQ(iterator.current_index(), 5);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(iterator.GetRegisterOperand(0).index(), reg_0.index());
EXPECT_EQ(iterator.GetRegisterOperandRange(0), 1);
ASSERT_TRUE(iterator.IsValid());
--iterator;
offset -= Bytecodes::Size(Bytecode::kLdaZero, OperandScale::kSingle);
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kLdaZero);
EXPECT_EQ(iterator.current_index(), 4);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
ASSERT_TRUE(iterator.IsValid());
--iterator;
offset -= Bytecodes::Size(Bytecode::kStar, OperandScale::kSingle);
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kStar);
EXPECT_EQ(iterator.current_index(), 3);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(iterator.GetRegisterOperand(0).index(), reg_0.index());
EXPECT_EQ(iterator.GetRegisterOperandRange(0), 1);
ASSERT_TRUE(iterator.IsValid());
--iterator;
offset -= Bytecodes::Size(Bytecode::kLdaConstant, OperandScale::kSingle);
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kLdaConstant);
EXPECT_EQ(iterator.current_index(), 2);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
[ast] Move AstValue implementation into Literal This eliminates the AstValue class, effectively moving its implementation into the Literal AstNode. This should cause no difference in behavior, but it does signal some shifts in the underlying system. Biggest changes include: - Reduction in AST memory usage - No duplicate HeapNumbers in Ignition constant pools - Non-String values are allocated either at constant pool creation time (or at boilerplate creation time for literals), rather than at AstValueFactory::Internalize() time. There are a variety of test-only/debug-only changes due to these switches as well. Bug: v8:6984 Change-Id: I5f178040ce2796d4e7370c24d1063419e1c843a1 Reviewed-on: https://chromium-review.googlesource.com/731111 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#49013}
2017-10-27 19:53:15 +00:00
EXPECT_EQ(iterator.GetConstantForIndexOperand(0)->Number(), heap_num_1);
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
ASSERT_TRUE(iterator.IsValid());
--iterator;
offset -= Bytecodes::Size(Bytecode::kStar, OperandScale::kSingle);
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kStar);
EXPECT_EQ(iterator.current_index(), 1);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
EXPECT_EQ(iterator.GetRegisterOperand(0).index(), reg_0.index());
EXPECT_EQ(iterator.GetRegisterOperandRange(0), 1);
ASSERT_TRUE(iterator.IsValid());
--iterator;
offset -= Bytecodes::Size(Bytecode::kLdaConstant, OperandScale::kSingle);
EXPECT_EQ(iterator.current_bytecode(), Bytecode::kLdaConstant);
EXPECT_EQ(iterator.current_index(), 0);
EXPECT_EQ(iterator.current_offset(), offset);
EXPECT_EQ(iterator.current_operand_scale(), OperandScale::kSingle);
[ast] Move AstValue implementation into Literal This eliminates the AstValue class, effectively moving its implementation into the Literal AstNode. This should cause no difference in behavior, but it does signal some shifts in the underlying system. Biggest changes include: - Reduction in AST memory usage - No duplicate HeapNumbers in Ignition constant pools - Non-String values are allocated either at constant pool creation time (or at boilerplate creation time for literals), rather than at AstValueFactory::Internalize() time. There are a variety of test-only/debug-only changes due to these switches as well. Bug: v8:6984 Change-Id: I5f178040ce2796d4e7370c24d1063419e1c843a1 Reviewed-on: https://chromium-review.googlesource.com/731111 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#49013}
2017-10-27 19:53:15 +00:00
EXPECT_EQ(iterator.GetConstantForIndexOperand(0)->Number(), heap_num_0);
[ignition] Rewrite reverse iterator as random iterator This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
2016-12-05 13:03:07 +00:00
ASSERT_TRUE(iterator.IsValid());
--iterator;
ASSERT_FALSE(iterator.IsValid());
}
} // namespace interpreter
} // namespace internal
} // namespace v8
Reference in New Issue Copy Permalink