In kArchSaveCallerRegisters, PushCallerSaved alone alters stack pointer
without informing `frame_access_state`. This commit compensate the
inconsistency by manually increasing the delta after pushing registers.
This affects systems (currently only ARM64) using stack pointer for
accessing variables stored on stack.
Bug: chromium:749486
Change-Id: Ic6da3826323d4fb1c545ade3d4d2cd4d1fed1843
Reviewed-on: https://chromium-review.googlesource.com/633606
Commit-Queue: Albert Mingkun Yang <albertnetymk@google.com>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47797}
This is a reland of 6daf3c77f1
Original change's description:
> [presubmit] Include test/common and test/fuzzer in cpplint
>
> These directories probably just did not exist when the cpplint paths
> were defined.
>
> R=machenbach@chromium.org
> CC=mstarzinger@chromium.org
>
> Change-Id: Ia6b641b3c106d86ceafb0c70b44ca241b4c80642
> Reviewed-on: https://chromium-review.googlesource.com/647807
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47786}
Change-Id: I15cd1b508cd3c6f5cd58cd5c5129174d8ced40d0
Reviewed-on: https://chromium-review.googlesource.com/649006
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47796}
We encode the reachability/liveness in the placement. After we prepare
use counts, the kUnknown placement means that the noe is unreachable.
Bug: v8:5267
Change-Id: Iad27159508f0aefb812b6394a257055f789fbe13
Reviewed-on: https://chromium-review.googlesource.com/646247
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47795}
Rename Managed::New to Managed::From (since it takes ownership of an
existing object), and re-introduce Managed::Allocate, which allocates
a new object and stores it in a Managed.
R=titzer@chromium.org
Change-Id: I20b0750697fbe7d56d3816b19919c31e389278b3
Reviewed-on: https://chromium-review.googlesource.com/645806
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47794}
This reverts commit 84c2dfce43.
Reason for revert:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/14876
Original change's description:
> Remove weak-list of optimized JS functions.
>
> This CL removes the weak-list of JS functions from the context
> and all the code that iterares over it. This list was being used
> mainly during deoptimization (for code unlinking) and during
> garbage collection. Removing it will improve performance of
> programs that create many closures and trigger many scavenge GC
> cycles.
>
> No extra work is required during garbage collection. However,
> given that we no longer unlink code from JS functions during
> deoptimization, we leave it as it is, and on its next activation
> we check whether the mark_for_deoptimization bit of that code is
> set, and if it is, than we unlink it and jump to lazy compiled
> code. This check happens in the prologue of every code object.
>
> We needed to change/remove the cctests that used to check
> something on this list.
>
> Working in x64, ia32, arm64, arm, mips64 and mips.
>
> Bug: v8:6637
> Change-Id: I7f192652c8034b16a9ea71303fa8e78cda3c48f3
> Reviewed-on: https://chromium-review.googlesource.com/600427
> Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47790}
TBR=mstarzinger@chromium.org,jarin@chromium.org,leszeks@chromium.org,bmeurer@chromium.org,jupvfranco@google.com
Change-Id: Ia4f1a8acf6ca5cd5c74266437a03d854b3739af2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6637
Reviewed-on: https://chromium-review.googlesource.com/647540
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47792}
This CL removes the weak-list of JS functions from the context
and all the code that iterares over it. This list was being used
mainly during deoptimization (for code unlinking) and during
garbage collection. Removing it will improve performance of
programs that create many closures and trigger many scavenge GC
cycles.
No extra work is required during garbage collection. However,
given that we no longer unlink code from JS functions during
deoptimization, we leave it as it is, and on its next activation
we check whether the mark_for_deoptimization bit of that code is
set, and if it is, than we unlink it and jump to lazy compiled
code. This check happens in the prologue of every code object.
We needed to change/remove the cctests that used to check
something on this list.
Working in x64, ia32, arm64, arm, mips64 and mips.
Bug: v8:6637
Change-Id: I7f192652c8034b16a9ea71303fa8e78cda3c48f3
Reviewed-on: https://chromium-review.googlesource.com/600427
Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47790}
Our current deserializers (startup & partial) use a system of static memory
reservations: required memory is determined at serialization time, which we
then request before deserialization and dole out as-needed during
deserialization.
Lazy builtin deserialization needs a bit more flexibility. On the one hand, the
amount of required memory varies since --lazy-deserialization can be switched
on and off at runtime.
On the other, builtin deserialization has been made order-independent, and we
can encounter references to builtins before they have been deserialized.
Both problems are solved by dynamically allocating required memory and
initializing the builtins table with the (yet uninitialized) builtin Code
objects.
Bug: v8:6624
Change-Id: Iee90992e91adb4ab45dae1acc81f64a108d12584
Reviewed-on: https://chromium-review.googlesource.com/647748
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47789}
These will tight-loop scanning primitives.
BUG=v8:6092
Change-Id: I9bf0f1952755bbede3c545c45fe2c4a210548171
Reviewed-on: https://chromium-review.googlesource.com/647526
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47788}
This reverts commit 6daf3c77f1.
Reason for revert: Need to fix violations in test/fuzzer first.
Original change's description:
> [presubmit] Include test/common and test/fuzzer in cpplint
>
> These directories probably just did not exist when the cpplint paths
> were defined.
>
> R=machenbach@chromium.org
> CC=mstarzinger@chromium.org
>
> Change-Id: Ia6b641b3c106d86ceafb0c70b44ca241b4c80642
> Reviewed-on: https://chromium-review.googlesource.com/647807
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47786}
TBR=machenbach@chromium.org,mstarzinger@chromium.org,clemensh@chromium.org
Change-Id: Ie20f0e9ef521c8da0c928bee241427fad694a440
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/647593
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47787}
These directories probably just did not exist when the cpplint paths
were defined.
R=machenbach@chromium.orgCC=mstarzinger@chromium.org
Change-Id: Ia6b641b3c106d86ceafb0c70b44ca241b4c80642
Reviewed-on: https://chromium-review.googlesource.com/647807
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47786}
For readability. Also make them constexpr, which allows to use them in
other constexpr contexts.
R=mstarzinger@chromium.org
Change-Id: Ia9ea9b4fb044bd1a011da887409bfbcbf6298fec
Reviewed-on: https://chromium-review.googlesource.com/647627
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47785}
This allows to reuse this logic in the wasm baseline compiler to
determine the location of our parameters.
R=mstarzinger@chromium.orgCC=titzer@chromium.org
Bug: v8:6600
Change-Id: I86e4d425d1c8aa35f0f722d311a2bd830b951d0a
Reviewed-on: https://chromium-review.googlesource.com/647628
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47784}
DeserializeLazy must be deserialized eagerly since it implements the
lazy deserialization mechanism.
Wasm currently requires their builtins to be immovable; and since we can
only efficiently allocate immovable code objects at deserialization
time, wasm builtins must be eager-loaded for now.
Bug: v8:6624
Change-Id: I9aae60385d4b08a34a52e12711ee1a492476f7cf
Reviewed-on: https://chromium-review.googlesource.com/647707
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47783}
As Blink needs a way to delete a property without running a script,
make Object::Delete use ENTER_V8_NO_SCRIPT if the receiver object is
not a JSProxy. Also makes Object::DeletePrivate use
ENTER_V8_NO_SCRIPT, too.
Bug: chromium:728583
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ib37959764b99a68d730d1bbc6dba410106d4f452
Reviewed-on: https://chromium-review.googlesource.com/608348
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Yuki Shiino <yukishiino@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47779}
Prior to this, AllocateJSArray would go ahead and allocate an empty
FixedArray as elements if passed any capacity that is not a compile-time
constant 0.
Things break later on since we rely on the fact that empty fixed arrays
are always canonicalize, and we use
obj.elements == empty_fixed_array_constant
interchangeably with
obj.elements.length == 0.
This CL introduces two new branches in AllocateJSArray: one if the
capacity is known to be non-zero; and another that explicitly
distinguishes between 0 and non-zero capacities.
Bug: chromium:760790
Change-Id: I7c22b19ce9ce15a46f91b0f75e6b4a1ff3a29a0f
Reviewed-on: https://chromium-review.googlesource.com/645959
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47776}
This reverts commit fbe184a602.
Reason for revert: Baseline performance test score established, re-enabling feature.
Original change's description:
> [modules] Temporarily disable IC support for namespace accesses
>
> To get a proper performance baseline after fixing the perf tests in
> https://chromium-review.googlesource.com/c/v8/v8/+/639396.
>
> This is intended to be reverted after a couple of hours.
>
> Change-Id: If36e4bfa5bd113599652f5c2016f886533af2746
> Reviewed-on: https://chromium-review.googlesource.com/639057
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47753}
TBR=adamk@chromium.org,jkummerow@chromium.org
Change-Id: Ia92e3247bc594e2fa6c937d379fa172244df2d8a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/647966
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47775}
This violates the style guide, and causes problems for jumbo builds.
R=ahaas@chromium.orgCC=mostynb@opera.com
Bug: chromium:746958
Change-Id: Ic583c41b94bfd9ecdb31a9ccadb2e842861fe7f4
Reviewed-on: https://chromium-review.googlesource.com/647710
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47774}
This required splitting wasm-run-utils.h in header and implementation,
since the anonymous namespace in wasm-run-utils.h is now gone.
This is a reasonable refactoring in itself.
R=titzer@chromium.orgCC=mstarzinger@chromium.org, mostynb@opera.com
Bug: chromium:746958
Change-Id: I0f3b30fef1865cd88eca37b69d0c3a9eb19e77ea
Reviewed-on: https://chromium-review.googlesource.com/647587
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47773}
In the BytecodeGraphBuilder we insert a SOFT deopt whenever we see an
IC whose state is UNINITIALIZED, i.e. a LOAD_IC or a STORE_IC. This
greatly reduces the size of the generated graphs (and also helps to
improve generated code quality). However for COMPARE_IC and BINARY_OP_IC
we used to stick in the generic JavaScript node instead, which does
generate code and might block optimizations because its sitting in
the effect chain. This is changed now to always SOFT deopt for
UNINITIALIZED instead, consistently with the other ICs.
Bug: v8:6760
Change-Id: I2ac7469fa86512a2fd909fdde2c6425977694811
Reviewed-on: https://chromium-review.googlesource.com/645858
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47771}
Saving/restoring only registers in the restricted set before calling
RecordWrite code stub, which prepares for turning on
`v8_enable_csa_write_barrier` on all architectures.
Bug: chromium:749486
Change-Id: I6c8ba0c1561513569218e80011673cf24c7d6127
Reviewed-on: https://chromium-review.googlesource.com/641531
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Albert Mingkun Yang <albertnetymk@google.com>
Cr-Commit-Position: refs/heads/master@{#47770}
For stack sizes and control depths, we were sometimes using uint32_t
and sometimes size_t.
This CL switches to uint32_t consistently.
R=titzer@chromium.org
Change-Id: I5ce3d63832bc926584b153cf248006cd78d77b97
Reviewed-on: https://chromium-review.googlesource.com/645861
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47769}
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}
This CL moves most of the logic of capturing simple stack frames from the
mentioned method into a FrameArrayBuilder class. This further encapsulates
that logic and makes it easier to refactor this code to use a callback
interface for walking the stack.
Bug:
Change-Id: Ib0b31d9eb8c4031aa64f393982889d0d02b56639
Reviewed-on: https://chromium-review.googlesource.com/645957
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47767}
After the FallThruTo in kExprEnd, the current block {c} is never
unreachable. Hence, the check for {c->unreachable} afterwards can be
removed.
In the loop case, the {TypeCheckFallThru} already adds entries for
non-existing values to the stack, so no need to {PushEndValues}.
Also, add more tests for the loop case.
R=titzer@chromium.org
Change-Id: I8737affaeed2ea663bd6ddafa36532ca9a7379bb
Reviewed-on: https://chromium-review.googlesource.com/645859
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47765}
This helps with patterns such as
((a[i] + n) + m) | 0
where we know n and m are small integers, and a[i] is a holey smi
array where we have never read a hole so far.
In that case, we still perform the additions with overflow checks
since we currently only propagate/use the truncation if the operation
outcome is in the safe-integer range (without taking feedback into
account). The problem here is that both 'n + a[i]' and '(n + a[i]) +
m' have type Union(Range(..., ...), NaN), even though the NaN will
never pass the Smi check on a[i].
This CL changes restricts the static type of
SpeculativeSafeInteger(Add|Subtract) to the safe integer range.
This is safe because we will always either truncate or use the feedback
(i.e., deopt if the inputs are not Signed32). In either case, the
result will always be in safe-integer range.
As a result, we will perform the second addition without
overflow check. Getting rid of the overflow check on the first
is done in a separate CL.
Bug: v8:5267,v8:6764
Change-Id: I27dba0fda832fc1f04477db6dd3495d5b4b2bd0b
Reviewed-on: https://chromium-review.googlesource.com/634903
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47763}
This adds support for lowering {JSCreateArguments} within outermost
frames of type {CreateArgumentsType::kMappedArguments}. It will hence
enable escape analysis to work with such objects and allow for further
optimization.
This also adds a new {NewMappedArgumentsElements} simplfied operator.
Note that escape analysis support for this new operator will be done as
a follow-up.
R=tebbi@chromium.org
Change-Id: I0e2fac25c654f796433f57b116964053b6b68635
Reviewed-on: https://chromium-review.googlesource.com/641454
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47761}
This adds an initial implementation of the DeserializeLazy builtin and
runtime function, as well as --lazy-deserialization and
--trace-lazy-deserialization feature flags.
Since lazy deserialization itself isn't implemented yet, DeserializeLazy
simply replaces itself with the appropriate builtin. The builtin_id is
loaded from the SFI, and the builtin itself is loaded from the Builtins
table.
Bug: v8:6624
Change-Id: I4ef8c3030a8cda19a086b8e569a24d97213b5ed8
Reviewed-on: https://chromium-review.googlesource.com/643289
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47757}
To get a proper performance baseline after fixing the perf tests in
https://chromium-review.googlesource.com/c/v8/v8/+/639396.
This is intended to be reverted after a couple of hours.
Change-Id: If36e4bfa5bd113599652f5c2016f886533af2746
Reviewed-on: https://chromium-review.googlesource.com/639057
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47753}
This makes several changes to SwitchStatement handling:
- Store the CaseClause list inline (as it's always allocated)
- Only rewrite with additional blocks if the Block Scope for
the switch statement isn't empty
- Use Parser::IgnoreCompletion() instead of inserting an additional
`undefined` ExpressionStatement
Bug: v8:6092
Change-Id: Ib08d0ba851dd8e78b3dc74782b8e554541e79182
Reviewed-on: https://chromium-review.googlesource.com/644176
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47751}
Since fullcodegen was removed, all baseline code runs in Ignition now,
so the code_is_interpreted parameter to FeedbackVector::ComputeCounts
is no longer needed.
Bug: v8:6409
Change-Id: I27842a4978079f8166f22db6c695b352a38e1d87
Reviewed-on: https://chromium-review.googlesource.com/646106
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47748}
