This extends the typing rule for NumberRound to deal with general number
inputs properly, thus addressing a long-standing TODO. We also add test
cases to ensure that the typing rule gets the corner cases for NaN and
-0 right.
Bug: v8:5267, v8:7109
Change-Id: Ia865ec1d6f8d96f20641bee96891740a9fc6e627
Reviewed-on: https://chromium-review.googlesource.com/792931
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49651}
This extends the typing rule for NumberCeil to deal with general number
inputs properly, thus addressing a long-standing TODO. We also add test
cases to ensure that the typing rule gets the corner cases for NaN and
-0 right.
Bug: v8:5267, v8:7109
Change-Id: I9154e47e58ad106791613db0030051f2a802a981
Reviewed-on: https://chromium-review.googlesource.com/792930
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49650}
Pull most JSTypedArray source arguments onto the fast path.
Same source & target elements-kinds simply call memmove. Other
combinations call directly into C and reuse ElementsAccessor logic.
Only overlapping source & target args with differing elements-kinds
remain on the slow runtime path.
Bug: v8:7123, v8:3590
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I80284b61478b0e3266b8f16bde8a56bd90f080b0
Reviewed-on: https://chromium-review.googlesource.com/788857
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49643}
Implement the new spec behavior that says construction from a neutered
buffer should throw after the ToIndex call on the length argument.
Bug: v8:6216
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I219a107730b53fca639bc813f68f7ddc27e79017
Reviewed-on: https://chromium-review.googlesource.com/789847
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49639}
Previously we only created synthetic variables in the parser and not
in the preparser, causing mismatch in the preparsed scope data.
This patch creates the variables in both parsers.
Bug: v8:5367
Change-Id: I9c511d0b9212bd36816956b06dc204b0b5920e1c
Reviewed-on: https://chromium-review.googlesource.com/789848
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49637}
Within SanitizeImports it is possible that JavaScript code gets executed
therefore we have to open the CodeSpaceMemoryModificationScope after
SanitizeImports.
R=clemensh@chromium.org
Bug: chromium:788469
Change-Id: Ide9bbd4ee4613b28380979d4a6c66d26e6a9406f
Reviewed-on: https://chromium-review.googlesource.com/789936
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49635}
This adds a fast path that avoids the runtime transition for JSArray
source arguments with {packed,holey} {smi,double} elements kinds.
The fast path currently calls straight into C and copies there using
elements accessor logic.
Local tests show a 4x speedup when copying from 1-element JSArrays.
As the source array becomes larger, the time spent copying elements
begins to dominate.
Bug: v8:3590
Change-Id: I05ebe54d7b255d0a76ad46ac11ce7cfd516b8ac8
Reviewed-on: https://chromium-review.googlesource.com/789010
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49634}
This fixes the computation of the {may_have_interesting_symbols} flag
for the last map computed in {Map::AddMissingTransitions} method. The
last map is allocated ahead of time, but the flag is only correct once
the descriptors are actually installed in the end.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-786020
BUG=chromium:786020
Change-Id: Iff97780609fe596437eb6bea85606a1c3bb2ac4c
Reviewed-on: https://chromium-review.googlesource.com/789839
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49631}
Previously, the class fields initializer function was stored on a
synthetic context allocated variable. This approach had sevaral
problems:
- We didn't know that class literal had fields until after we had
completely parsed the class literal. This meant that we had to go back
and fix up the scope of the constructor to have this synthetic
variable. This resulted in mismatch between parser and preparsed scope
data.
- This synthetic variable could potentially resolve to an initializer
of an outer class.
For ex:
class X extends Object {
c = 1;
constructor() {
var t = () => {
class P extends Object {
constructor() {
var t = () => { super(); };
t();
}
}
super();
}
t();
}
}
In this the inner class P could access the outer class X's initiliazer
function. We would have to maintain extra metadata to make sure this
doesn't happen.
Instead this new approach uses a private symbol to store the
initializer function on the class constructor itself.
For the base constructor case, we can simply check for a bit on the
constructor function literal to see if we need to emit code that loads
and calls this initializer function. Therefore, we don't pay the cost
of loading this function in case there are no class fields.
For the derived constructor case, there are two possiblities:
(a) We are in a super() call directly in the derived constructor:
In this case we can do a check similar to the base constructor check,
we can check for a bit on the derived constructor and emit code for
loading and calling the initializer function.
This is usually the common case and we don't pay any cost for not using
class fields.
(b) We are in a super() call inside an arrow function in the derived
constructor:
In this case, we /always/ emit code to load and call the initializer
function. If the function doesn't exist then we have undefined and we
don't call anything. Otherwise we call the function.
super() can't be called twice so even if we emit code to load and call
the initializer function multiple times, it doesn't matter because it
would have already been an error.
Bug: v8:5367
Change-Id: I7f77cd6493ff84cf0e430a8c1039bc9ac6941a88
Reviewed-on: https://chromium-review.googlesource.com/781660
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49628}
This is a reland of 4d3bc552b5
Original change's description:
> [coverage] add coverage for binary expressions
>
> Adds block-level coverage tracking for binary && and ||
> expressions. Introduces a BinaryOperation source-range
> for tracking the operations themselves and an Expression
> source-range, used for tracking NaryLogical expressions.
>
> This builds on work by jgruber@chromium.org in
> the issue.
>
> TBR=marja@chromium.org
> R=jgruber@chromium.org, rmcilroy@chromium.org
>
> Bug: v8:6660
> Change-Id: I83a81f13a3514a734c06948b2d3e91138fb00e18
> Reviewed-on: https://chromium-review.googlesource.com/754564
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49304}
Bug: v8:6660
Change-Id: I1c8571660d6c501d526886867bd841c49d5c44fd
Reviewed-on: https://chromium-review.googlesource.com/778288
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49613}
The existing access to the signatures is plain wrong. This CL fixes
this.
Note that cross-instance indirect calls are only enabled since a few
days (https://crrev.com/c/778159), which is why this bug was not
detected before.
R=titzer@chromium.org
Bug: chromium:787910
Change-Id: Iaac4d1d85840c921eb8554c5094933ec8d987802
Reviewed-on: https://chromium-review.googlesource.com/787312
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49607}
The typer's ToNumber (and thus ToInteger etc.) returns type None when
the input type is BigInt, but we weren't quite ready for that in a few
places.
R=jarin@chromium.org
Bug: v8:7121
Change-Id: Ib12c726338f1ec3dfb9ba5cf54b00cc8d1351a89
Reviewed-on: https://chromium-review.googlesource.com/785130
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49604}
The tsan skips were getting a bit spread all over the place. Added a
section for them below msan and asan to keep things together, where
the only cause for skipping the test is tsan.
Bug: v8:7093
Change-Id: I606c3ab2f23e4159c12c1e81d28e855412158f15
Reviewed-on: https://chromium-review.googlesource.com/785810
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49599}
The main reason why we currently don't see this fail is that block-scopes always appear to have an extension: the scope info object is stored there.
Bug:
Change-Id: I38f0c15387e235eeea9a57c95af0d9eb185dad2a
Reviewed-on: https://chromium-review.googlesource.com/785951
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49585}
This test used to run 10M loop iterations to trigger OSR. Let's run 5
instead and trigger OSR manually through the runtime.
Bug: v8:7093
Change-Id: Ie0cdb9389ca465bf433e81a17fa60c300edc3e29
Reviewed-on: https://chromium-review.googlesource.com/785693
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49579}
The test is flaky due to huge string allocation.
Bug: v8:7093
Change-Id: I2f17eb8b96b569d84a1f5c9549753fd0ab7fee89
Reviewed-on: https://chromium-review.googlesource.com/785351
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49575}
These tests can take up to 10 minutes on bots. Split them up to
increase parallelism.
Bug: v8:7093
Change-Id: Iabfd34a7f2476d4add51da807f2e987e8d1153c9
Reviewed-on: https://chromium-review.googlesource.com/785411
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49573}
This is a reland of 712fa67554.
Original change's description:
> [test] Add Liftoff variant
>
> Add a variant for testing the current state of the Liftoff
> implementation.
> This variant will only run on a subset of the bots, just like the
> --future variant.
>
> R=machenbach@chromium.org, hablich@chromium.org
>
> Bug: v8:7088, v8:6600
> Change-Id: If49fad3a8ed579356504b821a787326754f24e78
> Reviewed-on: https://chromium-review.googlesource.com/779420
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49504}
TBR=machenbach@chromium.orgCC=hablich@chromium.org
Bug: v8:7088, v8:6600
Change-Id: Ieb20020f07c70acaa64bb421763a41aa163a261b
Reviewed-on: https://chromium-review.googlesource.com/781499
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49531}
The integer value denoting the number of captures (and thus the size
of the list of captures created in @@replace [0]) can be controlled by
the user. This CL ensures we don't overflow and respect
Code::kMaxArguments, but note that it is still possible to trigger
OOMs through large lists.
Bug: chromium:786573
Change-Id: I19c88908c594487818d083b2ba423764ef91eae0
Reviewed-on: https://chromium-review.googlesource.com/779001
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49530}
This is a reland of 236298acbf.
Original change's description:
> [wasm] Unify deoptimization data
>
> Add methods to add deoptimization data and use them from all the places
> where we currently add them manually. Also add them to wasm-to-wasm
> wrappers compiled on table set, which was missing before, leading to
> the referenced bug.
>
> R=ahaas@chromium.org
>
> Bug: chromium:779292
> Change-Id: Ib9132d9faeb1092c46e22dd8196d201ce5c0942f
> Reviewed-on: https://chromium-review.googlesource.com/774838
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49452}
Bug: chromium:779292
Change-Id: I8219305fc894c50904db57e51245733f6613dcd3
Reviewed-on: https://chromium-review.googlesource.com/778159
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49508}
When collecting source ranges for conditionals (`a ? b : c`), include
the '?' and ':' tokens in the then- and else ranges, respectively.
Bug: v8:7098
Change-Id: I22315e2040c96c977e0b49e1fafe4228a6558471
Reviewed-on: https://chromium-review.googlesource.com/778321
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49484}
This CL also includes fixes for CF issues found while the previous
reland was active.
Bug: v8:5799, chromium:783902, chromium:783926, chromium:783822
Change-Id: I1f7d9b037d90838469c45f5d72771a77444c662e
Reviewed-on: https://chromium-review.googlesource.com/764067
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49457}
This reverts commit 236298acbf.
Reason for revert: suspected cause of failures on GC stress bots:
https://build.chromium.org/p/client.v8/builders/V8%20Mac%20GC%20Stress/builds/16341https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/16269
Original change's description:
> [wasm] Unify deoptimization data
>
> Add methods to add deoptimization data and use them from all the places
> where we currently add them manually. Also add them to wasm-to-wasm
> wrappers compiled on table set, which was missing before, leading to
> the referenced bug.
>
> Drive-by: Disable non-applicable MaybeHandle constructors to allow
> overloading functions with different Handle types.
>
> R=ahaas@chromium.org
>
> Bug: chromium:779292
> Change-Id: Ib9132d9faeb1092c46e22dd8196d201ce5c0942f
> Reviewed-on: https://chromium-review.googlesource.com/774838
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49452}
TBR=ahaas@chromium.org,clemensh@chromium.org
Change-Id: I02fb49d2ece8e04ac5fb26f618bfe6fb2f133d06
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:779292
Reviewed-on: https://chromium-review.googlesource.com/777079
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49455}
This reverts commit 4d3bc552b5.
Reason for revert: https://crbug.com/785778
Original change's description:
> [coverage] add coverage for binary expressions
>
> Adds block-level coverage tracking for binary && and ||
> expressions. Introduces a BinaryOperation source-range
> for tracking the operations themselves and an Expression
> source-range, used for tracking NaryLogical expressions.
>
> This builds on work by jgruber@chromium.org in
> the issue.
>
> TBR=marja@chromium.org
> R=jgruber@chromium.org, rmcilroy@chromium.org
>
> Bug: v8:6660
> Change-Id: I83a81f13a3514a734c06948b2d3e91138fb00e18
> Reviewed-on: https://chromium-review.googlesource.com/754564
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49304}
TBR=rmcilroy@chromium.org,marja@chromium.org,jgruber@chromium.org,ben@npmjs.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:6660
Change-Id: Ie017c528604b2e01400f527511413eaea5786198
Reviewed-on: https://chromium-review.googlesource.com/776768
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49454}
Both of these features were shipped in Chrome 62.
Bug: v8:4545, v8:6172
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Ie00dcbeded7517a15696d4a78fcfbbf162919923
Reviewed-on: https://chromium-review.googlesource.com/775601
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49453}
Add methods to add deoptimization data and use them from all the places
where we currently add them manually. Also add them to wasm-to-wasm
wrappers compiled on table set, which was missing before, leading to
the referenced bug.
Drive-by: Disable non-applicable MaybeHandle constructors to allow
overloading functions with different Handle types.
R=ahaas@chromium.org
Bug: chromium:779292
Change-Id: Ib9132d9faeb1092c46e22dd8196d201ce5c0942f
Reviewed-on: https://chromium-review.googlesource.com/774838
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49452}
This test uses 136GB of memory which is too much for our MIPS boards.
NOTRY=true
Bug: v8:7093
Change-Id: I382bf0832da6ae74241e89a2016c3738f03979fd
Reviewed-on: https://chromium-review.googlesource.com/776765
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49443}
It was shipped in Chrome 62.
Bug: v8:5070
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I77119540411d1fe15691d40012cb96f4e2e45048
Reviewed-on: https://chromium-review.googlesource.com/776154
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49434}
"AbsoluteDivSmall" had a shortcut path for abs(divisor) == 1 where
it would simply return the dividend as result. However, its caller
"Divide" was blissfully ignorant of this trick and would therefore
simply set the value's sign as needed, modifying the input.
This CL prevents that, while continuing to avoid the full division
algorithm for abs(divisor) == 1.
Bug: v8:6791
Change-Id: I04cdc93f5ed2a696587c35c754e68f07012dd1a9
Reviewed-on: https://chromium-review.googlesource.com/772332
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49433}
Reland of https://chromium-review.googlesource.com/c/v8/v8/+/727893
The crashes should be fixed by https://chromium-review.googlesource.com/c/v8/v8/+/763531
Original change's description:
> Revert "Reland^5 "[turbofan] eagerly prune None types and deadness from the graph""
>
> This reverts commit ac0661b358.
>
> Reason for revert: Clusterfuzz unhappy: chromium:783019 chromium:783035
>
> Original change's description:
> > Reland^5 "[turbofan] eagerly prune None types and deadness from the graph"
> >
> > This gives up on earlier attempts to interpret DeadValue as a signal of
> > unreachable code. This does not work because free-floating dead value
> > nodes, and even pure branch nodes that use them, can get scheduled so
> > early that they get reachable. Instead, we now eagerly remove branches
> > that use DeadValue in DeadCodeElimination and replace DeadValue inputs
> > to value phi nodes with dummy values.
> >
> > Reland of https://chromium-review.googlesource.com/715716
> >
> > Bug: chromium:741225 chromium:776256
> > Change-Id: I251efd507c967d4a8882ad8fd2fd96c4185781fe
> > Reviewed-on: https://chromium-review.googlesource.com/727893
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#49188}
>
> TBR=jarin@chromium.org,tebbi@chromium.org
>
> Bug: chromium:741225 chromium:776256 chromium:783019 chromium:783035
> Change-Id: I6a8fa3a08ce2824a858ae01817688e63ed1f442e
> Reviewed-on: https://chromium-review.googlesource.com/758770
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49262}
TBR=jarin@chromium.org,tebbi@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:741225 chromium:776256 chromium:783019 chromium:783035
Change-Id: I6c02b4beb02997ec34015ed2f6791a93c70f5e36
Reviewed-on: https://chromium-review.googlesource.com/772150
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49429}
This is a reland of 77b0baa649.
Original change's description:
> [wasm] Fix importing wasm-lazy-compile stubs
>
> If two modules use lazy compilation, and one imports a function of
> another, we are unwrapping the js-to-wasm wrapper of the export. This
> was failing so far, because during unwrapping we did not find the wasm
> code.
> This CL fixes this by also recognizing WasmCompileLazy stubs as "wasm
> code".
>
> R=ahaas@chromium.org
>
> Bug: chromium:779569, v8:5991
> Change-Id: If2260c3721e3746a7635b9d0182fd520df2fb773
> Reviewed-on: https://chromium-review.googlesource.com/771672
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49405}
Bug: chromium:779569, v8:5991
Change-Id: I4818e933467bd5a040f1514b8fc18db219a092c7
Reviewed-on: https://chromium-review.googlesource.com/774538
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49426}
When initializing the stack state at a merge point, don't force all
stack slots into registers. Allow constants to stay constants as long
as they are not part of the merge. Otherwise we might break assumptions
of outer blocks which then try to merge a register into a constant and
fail.
Also, add some documentation to {InitMergeStackSlot} to document the
intent of the implementation.
R=titzer@chromium.org
Bug: v8:784050, v8:6600
Change-Id: I3a4c83b446909027be075d3207cb7c748a6b1aad
Reviewed-on: https://chromium-review.googlesource.com/766353
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49423}
This reverts commit 77b0baa649.
Reason for revert: Breaks on win64 bot: https://logs.chromium.org/v/?s=chromium%2Fbb%2Fclient.v8%2FV8_Win64_-_debug%2F20172%2F%2B%2Frecipes%2Fsteps%2FCheck%2F0%2Flogs%2Flazy-compilation%2F0
Original change's description:
> [wasm] Fix importing wasm-lazy-compile stubs
>
> If two modules use lazy compilation, and one imports a function of
> another, we are unwrapping the js-to-wasm wrapper of the export. This
> was failing so far, because during unwrapping we did not find the wasm
> code.
> This CL fixes this by also recognizing WasmCompileLazy stubs as "wasm
> code".
>
> R=ahaas@chromium.org
>
> Bug: chromium:779569, v8:5991
> Change-Id: If2260c3721e3746a7635b9d0182fd520df2fb773
> Reviewed-on: https://chromium-review.googlesource.com/771672
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49405}
TBR=ahaas@chromium.org,clemensh@chromium.org
Change-Id: If5ab7b9de95ef662a65a6a5b919fa1f13aa492cd
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:779569, v8:5991
Reviewed-on: https://chromium-review.googlesource.com/774518
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49409}
Previously, we had lazy parsing of class constructor disabled when a
class literal had class fields because we were using a reference to
the initializer function variable to load the function and call it.
Instead, in this patch, we use the scope analysis to lookup this
initializer function variable.
Bug: v8:5367
Change-Id: Ib73d7e6abed33c04d1f574e7976bea4869d54757
Reviewed-on: https://chromium-review.googlesource.com/768384
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49406}
If two modules use lazy compilation, and one imports a function of
another, we are unwrapping the js-to-wasm wrapper of the export. This
was failing so far, because during unwrapping we did not find the wasm
code.
This CL fixes this by also recognizing WasmCompileLazy stubs as "wasm
code".
R=ahaas@chromium.org
Bug: chromium:779569, v8:5991
Change-Id: If2260c3721e3746a7635b9d0182fd520df2fb773
Reviewed-on: https://chromium-review.googlesource.com/771672
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49405}
When calling the CWasmEntry in order to call from the interpreter to a
wasm function, the given buffer must hold the arguments, and must also
have enough space to hold the return values. We were missing the second
part, hence we failed when there are no parameters, but a return.
R=ahaas@chromium.org
Bug: chromium:784125
Change-Id: I08d417cae60eea64fda8a72e898dbed9f3e88148
Reviewed-on: https://chromium-review.googlesource.com/771633
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49402}
We need to explicitly rule out negative indices for the out-of-bounds
case, otherwise we can end up with a monomorphic KeyedLoadIC that allows
OOB accesses, but doesn't properly check whether there are properties
with negative integer names on the receiver.
Bug: chromium:784835
Change-Id: Ic3ef5438b76094f024de0c6348183fb62b32088c
Reviewed-on: https://chromium-review.googlesource.com/774278
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49396}
The backing store fixed array for collections needs to be allocated
in LOS if it exceeds the maximum regular heap object size.
Drive-by-fix: Only store fixed array map once as per TODO.
Bug: chromium:784862
Change-Id: I6b4dd2e45153ae107171e21bc7448e0d9b54b0ed
Reviewed-on: https://chromium-review.googlesource.com/771150
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49378}
Adds a stress-background-compile mode which runs compilation on a background
thread at the same time as compiling on the main thread to flush out races.
This is added as one of the variants, removing stress_asm_validation since this
is no longer a useful variant.
BUG=v8:5203
Change-Id: I73dd9f21d9b6da4a4cb39c05061aa24116e6c5ad
Reviewed-on: https://chromium-review.googlesource.com/741746
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49376}
Previously, the Parser stored a Scope alongside a RewritableExpression
for each potential destructuring assignment. This Scope was later used
during rewriting to set the correct context for the rewriting. But this
approach failed if a new Scope was inserted into the Scope chain between
the time the assignment was parsed and when it was rewritten.
By storing the Scope directly in RewritableExpression,
ReparentExpressionScopes() is able to appropriately re-scope such
expressions prior to their rewriting.
Bug: chromium:779457
Change-Id: Ieb429a3da841f76d5798610af59da4fccb000652
Reviewed-on: https://chromium-review.googlesource.com/767666
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49368}
Make sure we have at least two elements in the Map, otherwise we don't
perform a proper dictionary lookup.
Bug: chromium:781218
Change-Id: I471e3822b95c15e3a5b2ac54c8ad1f030bd54d40
Reviewed-on: https://chromium-review.googlesource.com/768708
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49345}
- Remove weak-collection.js
- Adds TFJ builtins for WeakSet and WeakMap constructors
- Unified helpers and constructor behavior into a BaseCollectionsAssembler
- Fast paths for...
- unmodified constructor function
- argument is a fast JS array
- entries are fast JS arrays, for Map/WeakMap
- no arguments passed
Quick benchmarks shows significant improvements (1.12x - 5.7x!) for ALL collection constructors (weak and non-weak):
https://github.com/peterwmwong/v8-perf/blob/master/weakcollection-constructor/README.md
More could be done for performance. Currently we always call out to JS to add entries, if we knew the prototype was unmodified, we could call the builtins directly.
Bug: v8:5049, v8:6604
Change-Id: Id7912c1eed5bcf512df7fd6238f04166a8a5937e
Reviewed-on: https://chromium-review.googlesource.com/760385
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49343}
Fix two more places where StringToBigInt differs from parseInt:
- Binary and octal radix prefixes are supported
- Trailing non-whitespace junk is not allowed
This is done with a new Behavior enum in BigIntParseIntHelper,
along with a couple of bool configuration flags in StringToIntHelper.
Bug: v8:6791, v8:7038
Change-Id: Ib91bfc5ccb04ad0dd6c99bc81e19c1239264a469
Reviewed-on: https://chromium-review.googlesource.com/764595
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49335}
This fixes a corner-case where resuming a suspended generator would not
perform stack overflow checks and hence cause the stack to grow without
bounds.
R=neis@chromium.org
BUG=chromium:781583
Change-Id: Ib04116e489ac6b962cb821263860497abb57bbae
Reviewed-on: https://chromium-review.googlesource.com/765953
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49327}
The only empty PropertyArray is the empty_property_array object on the
isolate. Allowing empty PropertyArrays causes the turbofan to ignore the
existing hash when growing the backing store again. We currently only end
up with the empty PropertyArray when following back transitions.
Bug: chromium:781218, chromium:783713
Change-Id: If41dd09b965cdc8d957b9ca50ba3c8a7f4254769
Reviewed-on: https://chromium-review.googlesource.com/763230
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49318}
Adds block-level coverage tracking for binary && and ||
expressions. Introduces a BinaryOperation source-range
for tracking the operations themselves and an Expression
source-range, used for tracking NaryLogical expressions.
This builds on work by jgruber@chromium.org in
the issue.
TBR=marja@chromium.orgR=jgruber@chromium.org, rmcilroy@chromium.org
Bug: v8:6660
Change-Id: I83a81f13a3514a734c06948b2d3e91138fb00e18
Reviewed-on: https://chromium-review.googlesource.com/754564
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49304}
This is a reland of 6c6132880a
Original change's description:
> [Liftoff] Implement parallel register moves
>
> This was not implemented so far, leading to lots of clusterfuzz issues.
> Testing this feature would require complicating the interface a lot and
> exposing more implementation details in the header file, hence we just
> go with regression tests for now.
>
> R=ahaas@chromium.org, titzer@chromium.org
>
> Bug: v8:6600, chromium:782280
> Change-Id: I12863f3eb59a8dffdcc7d3bfb8e1f0ae0eec15ee
> Reviewed-on: https://chromium-review.googlesource.com/758772
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49286}
Bug: v8:6600, chromium:782280
Change-Id: I82a75bfeaf83dc63a2917da3ccdc4721c5d689e7
Reviewed-on: https://chromium-review.googlesource.com/763387
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49292}
This reverts commit 6c6132880a.
Reason for revert: breaks compilation on win64 bot: https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20msvc/builds/69
Original change's description:
> [Liftoff] Implement parallel register moves
>
> This was not implemented so far, leading to lots of clusterfuzz issues.
> Testing this feature would require complicating the interface a lot and
> exposing more implementation details in the header file, hence we just
> go with regression tests for now.
>
> R=ahaas@chromium.org, titzer@chromium.org
>
> Bug: v8:6600, chromium:782280
> Change-Id: I12863f3eb59a8dffdcc7d3bfb8e1f0ae0eec15ee
> Reviewed-on: https://chromium-review.googlesource.com/758772
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49286}
TBR=titzer@chromium.org,ahaas@chromium.org,clemensh@chromium.org
Change-Id: I386983da7f9f03d54cef2190b01fd2cc5785966e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6600, chromium:782280
Reviewed-on: https://chromium-review.googlesource.com/763367
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49289}
This was not implemented so far, leading to lots of clusterfuzz issues.
Testing this feature would require complicating the interface a lot and
exposing more implementation details in the header file, hence we just
go with regression tests for now.
R=ahaas@chromium.org, titzer@chromium.org
Bug: v8:6600, chromium:782280
Change-Id: I12863f3eb59a8dffdcc7d3bfb8e1f0ae0eec15ee
Reviewed-on: https://chromium-review.googlesource.com/758772
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49286}
There were some places left where that could happen.
Bug: chromium:782754
Change-Id: I1db1f5b361cdf443b730a220c0e569ad48dd298d
Reviewed-on: https://chromium-review.googlesource.com/758841
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49283}
I made a mistake in yesterday's cleanup.
R=jarin@chromium.org
Bug: chromium:783051
Change-Id: Iabd7403096197ce8e54d46e079bc9a70aa98578d
Reviewed-on: https://chromium-review.googlesource.com/758765
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49266}
Since the deoptimizer generalizes maps for all materialized objects, it
must make sure that none of the object's fields contain mutable heap numbers
(only double fields are allowed to point to mutable heap numbers). With this CL,
we simply change any mutable heap numbers in property arrays to immutable ones.
This could be dangerous if some non-materialized object could point to this
property array, but this cannot happen because interpreter registers cannot
refer to naked property arrays.
Bug: chromium:776309
Change-Id: I897b604fa804de673710cfa3ba0595dbd9f80eeb
Reviewed-on: https://chromium-review.googlesource.com/759781
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49263}
This reverts commit ac0661b358.
Reason for revert: Clusterfuzz unhappy: chromium:783019 chromium:783035
Original change's description:
> Reland^5 "[turbofan] eagerly prune None types and deadness from the graph"
>
> This gives up on earlier attempts to interpret DeadValue as a signal of
> unreachable code. This does not work because free-floating dead value
> nodes, and even pure branch nodes that use them, can get scheduled so
> early that they get reachable. Instead, we now eagerly remove branches
> that use DeadValue in DeadCodeElimination and replace DeadValue inputs
> to value phi nodes with dummy values.
>
> Reland of https://chromium-review.googlesource.com/715716
>
> Bug: chromium:741225 chromium:776256
> Change-Id: I251efd507c967d4a8882ad8fd2fd96c4185781fe
> Reviewed-on: https://chromium-review.googlesource.com/727893
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49188}
TBR=jarin@chromium.org,tebbi@chromium.org
Bug: chromium:741225 chromium:776256 chromium:783019 chromium:783035
Change-Id: I6a8fa3a08ce2824a858ae01817688e63ed1f442e
Reviewed-on: https://chromium-review.googlesource.com/758770
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49262}
R=yangguo@chromium.org
This is a reland of
for the no-i18n configuration.
https: //chromium-review.googlesource.com/c/v8/v8/+/571746 with a fix
Bug:
Change-Id: I3e654791267b20fb3703ad4220404d8078f43440
Reviewed-on: https://chromium-review.googlesource.com/758999
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Erik Corry <erikcorry@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49251}
This patch adds support for Regional_Indicator within Unicode property
escapes in regular expressions.
The Regional_Indicator binary property was added in Unicode v10 and is
supported in ICU 60.1.
An `#if` directive is used to prevent breaking Node.js until they
update their ICU.
BUG=v8:4743
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I7acec13c8ae7552558a0f852937984bba828e738
Reviewed-on: https://chromium-review.googlesource.com/758273
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49250}
Like CSP flag 'unsafe-eval', which communicates if both JS source
files and WASM binary files may be compiled, this CL adds a similar
flag for the compilation of WASM binary files.
That is, a WASM binary file will be compiled only if the new flag is
defined, or the flag for 'unsafe-eval' allows it. These flags are
implemented as callback functions on the isolate. The callbacks get a
(CSP) context, and a string, and returns the corresponding value of
the flag.
Both callbacks are initialized with the nullptr, and is used to
communicate that no CSP policy is defined. This allows this concept to
work, independent of it running in Chrome.
It also does a small clean up in api.cc to use macro CALLER_SETTERS,
instead of explicit code when appropriate.
Bug: v8:7041
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Idb3356574ae2a298057e6b7bccbd3492831952ae
Reviewed-on: https://chromium-review.googlesource.com/759162
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Eric Holk <eholk@chromium.org>
Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49243}
StoreDataPropertyInLiteral doesn't throw (because the previous uses of
this didn't throw), but class fields can throw on defining the
property which means we can't use this. Changing to CreateDataProperty
runtime call instead.
Bug: v8:5367
Change-Id: I1ab45413b121972dd18fe2b35a0cedd8efe0e0bf
Reviewed-on: https://chromium-review.googlesource.com/757824
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49239}
This patch adds support for Emoji_Component within Unicode property
escapes in regular expressions.
The Emoji_Component binary property was added in Emoji data v5
and is supported in ICU 60.1.
An `#if` directive is used to prevent breaking Node.js until they
update their ICU.
BUG=v8:4743
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: If1b49a4c175e88f1840ca5ef8d57829d6d8c3291
Reviewed-on: https://chromium-review.googlesource.com/758261
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49229}
The C_WASM_ENTRY only calls wasm code, so (outgoing) parameters of this
code are always untagged.
R=ahaas@chromium.org
Bug: v8:7049
Change-Id: I989908eea668bd56aa88f3f1744105d218584ef1
Reviewed-on: https://chromium-review.googlesource.com/758245
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49221}
The regexp fast path in MaybeCallFunctionAtSymbol had an issue in which
we'd call ToString after checking that the given {object} was a fast
regexp and deciding to take the fast path. This is invalid since
ToString() can call into user-controlled JS and may mutate {object}.
There's no way to place the ToString call correctly in this instance:
1 before BranchIfFastRegExp, it's a spec violation if we end up on the
slow regexp path;
2 the problem with the current location is already described above;
3 and we can't place it into the fast-path regexp builtin (e.g.
RegExpReplace) either due to the same reasons as 1.
The solution in this CL is to restrict the fast path to string
arguments only, i.e. cases where ToString would be a nop and can safely
be skipped.
Bug: chromium:782145
Change-Id: Ifd35b3a9a6cf2e77c96cb860a8ec98eaec35aa85
Reviewed-on: https://chromium-review.googlesource.com/758257
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49213}
Creates a new initializer function to instantiate instance class
fields in a base class.
An initializer function (similar to the one created for static fields)
is created during class declaration and assigned to a synthetic
context allocated variable.
This function is loaded from the variable during instantiation (when
the constructor is run) and run.
Bug: v8:5367
Change-Id: Ie11c2183b3001234ae41d7bcc2cb9b02c0764ab5
Reviewed-on: https://chromium-review.googlesource.com/754445
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49207}
This gives up on earlier attempts to interpret DeadValue as a signal of
unreachable code. This does not work because free-floating dead value
nodes, and even pure branch nodes that use them, can get scheduled so
early that they get reachable. Instead, we now eagerly remove branches
that use DeadValue in DeadCodeElimination and replace DeadValue inputs
to value phi nodes with dummy values.
Reland of https://chromium-review.googlesource.com/715716
Bug: chromium:741225 chromium:776256
Change-Id: I251efd507c967d4a8882ad8fd2fd96c4185781fe
Reviewed-on: https://chromium-review.googlesource.com/727893
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49188}
The bytecode generator has special handling for comparing the result of
the typeof operator against a string literal. This needs to be adapted
for bigints.
R=jkummerow@chromium.org, mythrie@chromium.org
Bug: v8:6791
Change-Id: I42d6c9e9225ce05e19393f10e01ae496ecb70c9c
Reviewed-on: https://chromium-review.googlesource.com/753465
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49172}
Actually all it does is throw a TypeError.
R=jkummerow@chromium.org
Bug: v8:6791
Change-Id: I884da4eaa937519c07c3516a1713829f52e28ad8
Reviewed-on: https://chromium-review.googlesource.com/753730
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49171}
This test uses a lot of memory and is causing OOM crashes on bots.
Bug: v8:7042
Change-Id: I63ff4d44ca8e26b65875df53ebd235976183c558
Reviewed-on: https://chromium-review.googlesource.com/755593
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49161}
When initializing the cache state for a merge, we should never use
registers multiple times. Other code paths leading to the same merge
point might provide different values for the different slots there.
R=ahaas@chromium.org
Bug: v8:7035, v8:6600
Change-Id: I8e409b494af0fdc1a5045ec04571611b97fcaf86
Reviewed-on: https://chromium-review.googlesource.com/754816
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49150}
The maximum length of the chars in bytes was hardcoded and was not
updated with the increase in string length on 64-bit platforms.
The other platforms don't do this debug check so they don't need
updating.
Bug: chromium:779407
Change-Id: I94fd946f9e67b39075c1f7eed14a20e9db126a72
Reviewed-on: https://chromium-review.googlesource.com/753584
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49142}
If the destination register of a binop is the same register as the
right hand side, we would first move the left hand side into that
register (overwriting the value of the rhs), and then use the rhs.
This CL fixes this issue and adds a regression test.
R=ahaas@chromium.org
Bug: v8:6600, v8:7033
Change-Id: Ief90b5bcffc65823037bc57fb00741b2448e6375
Reviewed-on: https://chromium-review.googlesource.com/753462
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49137}
We must throw a SyntaxError only when failing to convert a string. In
the other cases we must throw a TypeError.
R=jkummerow@chromium.org
Bug: v8:6791
Change-Id: I802d8b6830b341f87e46e7de198af74ba95b8658
Reviewed-on: https://chromium-review.googlesource.com/752803
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49131}
This reverts commit e83ee94565.
Reason for revert: Check failure in regress-v8-6940.js
Original change's description:
> RegExp: Add the ability to switch flags on and off within the regexp.
>
> This is a reland of https://chromium-review.googlesource.com/c/v8/v8/+/752522
> which was itself a reupload of
> https://chromium-review.googlesource.com/c/v8/v8/+/571746 where reviews took
> place.
>
> R=yangguo@chromium.org
>
> Bug:
> Change-Id: Ia4dbdd6e9a362e272753ff10dc66b7f72d81ee20
> Reviewed-on: https://chromium-review.googlesource.com/753596
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Erik Corry <erikcorry@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49129}
TBR=yangguo@chromium.org,erikcorry@chromium.org
Change-Id: I5ee94c47606101d06010c9e6b4b78ca51566b60a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/754682
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49130}
The condition for bounds check generation was not in sync with the
condition that was used for the actual access, which lead to invalid
memory accesses when the array protector was invalid.
Tbr: tebbi@chromium.org
Bug: chromium:781506, chromium:781494, chromium:781457, chromium:781285, chromium:781381, chromium:781380, v8:6936, v8:7014, v8:7027
Change-Id: Ia5b2ad02940292572ed9b37abd3f9ffaa6d7a26b
Reviewed-on: https://chromium-review.googlesource.com/753590
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49124}
This patch evaluates computed properties in the order of declaration
during class definition time.
This patch creates a synthetic variable to store the result of
evaluating a computed property and then looks this up in the
initializer function.
Bug: v8:5367
Change-Id: I4182c6a01196d2538991818142890f6afb0e532b
Reviewed-on: https://chromium-review.googlesource.com/752567
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49115}
We don't use ICs for the Array.prototype and the Object.prototype
because the runtime has to be able to intercept them properly (for the
global protectors). So we better make sure that TurboFan doesn't
outsmart the system by storing to elements of either prototype directly.
Bug: chromium:781116
Change-Id: I0f521601ef02c1b21018abd1bf1028fd8a811e84
Reviewed-on: https://chromium-review.googlesource.com/753089
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49101}
This reverts commit 68212c80c3.
Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20noi18n%20-%20debug/builds/17200
Original change's description:
> RegExp: Add the ability to switch flags on and off within the regexp
>
> R=yangguo@chromium.org
>
> This is a reupload of https://chromium-review.googlesource.com/c/v8/v8/+/571746
> with a different user, since the other one was not allowed to commit to V8 any
> more.
>
> Bug:
> Change-Id: I6171afd44e514f6c934390faab6f9bee3953ac77
> Reviewed-on: https://chromium-review.googlesource.com/752522
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49098}
TBR=erik.corry@gmail.com,yangguo@chromium.org,erikcorry@chromium.org,jgruber@chromium.org
Change-Id: I651c5618f09f43104af50cb1319ab7b49011573e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/752802
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49099}
This turns on the existing --internalize_on_the_fly flag for the
MEGAMORPHIC KeyedLoadIC to properly internalize strings before
looking up the property. This avoids the otherwise taken runtime
call to %KeyedGetProperty, which is definitely slower.
Initially the --internalize_on_the_fly flag was turned off because
internalizing strings on the fly causes too much traffic on the
megamorphic stub cache. We avoid this problem here by not probing
the stub cache in that case, which still gives the benefit of not
having to go to the runtime.
This improves the babylon test on the web-tooling-benchmark by around
2-3% and will probably also help with several tests (like React or
Ember) on the Speedometer benchmark.
If this CL causes trouble (i.e. tanks something important), we can
just turn off the --internalize_on_the_fly flag again.
Bug: v8:6936, v8:7026
Change-Id: If295ed3fd013f8b0ff031f9979e7df21dab817b6
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/751464
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49093}
- Add WeakMapPrototypeDelete and WeakSetPrototypeDelete TFJ builtins
- Fast paths when it's not necessary to shrink the table
- Add WeakCollectionDelete TFS
Some quick benchmarks shows 1.4x - 2.15x gains in performance.
https://github.com/peterwmwong/v8-perf/blob/master/weakcollection-delete/README.md
Bug: v8:5049, v8:6604
Change-Id: I14036df153f3a0242f9083d751658b868b16660a
Reviewed-on: https://chromium-review.googlesource.com/743864
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49076}
The existing stack check only checked the number of stack frames on the
stack, not the actual size of the stack frames. In the test case, each
stack frame is huge, and the interpreter runs out of memory before the
stack check stops the execution. With this change we take the size of
the value stack and the size of the control stack and compare their sum
to the stack limit of V8. Note that this stack limit is kind of
arbitrary, because the stack space of the interpreter is not on the
actual runtime stack but allocated in zone memory, and the stack check
exists to simulate stack overflows in compiled code, not to prevent
actual stack overflows.
R=clemensh@chromium.org
TEST=mjsunit/regress/wasm/regress-778917
Bug: chromium:778917
Change-Id: Ife47631fcb1a178a68facab1e42c0069b12c0155
Reviewed-on: https://chromium-review.googlesource.com/744003
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49071}
Proxy's call trap can be used to cause recursion.
R=bmeurer@chromium.org, tebbi@chromium.org
Bug: chromium:779344
Change-Id: I19c989f618f7230028ebe18c3415bc3f4bd72b93
Reviewed-on: https://chromium-review.googlesource.com/743782
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49069}
This CL adds support for two byte string comparisons to the StringEqual
builtin, which so far was bailing out to the generic %StringEqual
runtime function whenever any two-byte string was involved. This made
comparisons that involved two-byte strings, either comparing them to
one-byte strings or comparing two two-byte strings, up to 3x slower than
if only one-byte strings were involved.
With this change, all direct string (SeqString or ExternalString)
equality checks are roughly on par now, and the weird performance cliff
is gone. On the micro-benchmark from the bug we go from
stringEqualBothOneByteSeqString: 162 ms.
stringEqualTwoByteAndOneByteSeqString: 446 ms.
stringEqualOneByteAndTwoByteSeqString: 438 ms.
stringEqualBothTwoByteSeqString: 472 ms.
to
stringEqualBothOneByteSeqString: 151 ms.
stringEqualTwoByteAndOneByteSeqString: 158 ms.
stringEqualOneByteAndTwoByteSeqString: 166 ms.
stringEqualBothTwoByteSeqString: 160 ms.
which is the desired result. On the esprima test of the
web-tooling-benchmark we seem to improve by 1-2%, which corresponds to
the savings of going to the runtime for many StringEqual comparisons.
Drive-by-cleanup: Introduce LoadAndUntagStringLength helper into the CSA
with proper typing to avoid the unnecessary shifts on 64-bit platforms
when keeping the length tagged initially in StringEqual.
Bug: v8:4913, v8:6365, v8:6371, v8:6936, v8:7022
Change-Id: I566f4b80e217513775ffbd35e0480154abf59b27
Reviewed-on: https://chromium-review.googlesource.com/749223
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49067}
The parser now throws for literals that are too big for the runtime
to support, thus avoiding CHECK-failures further down the line.
Tbr: rmcilroy@chromium.org
Bug: v8:6791
Change-Id: Ie45ddebb8aa9e7a30e8b6b74f99916b700e38e4a
Reviewed-on: https://chromium-review.googlesource.com/747682
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49059}
Objects with both dictionary and non-dictionary maps can store their
hash in the {properties} field when they have no other properties.
Bug: chromium:778952
Change-Id: I8ac8c31eaac32116415e3c65cef8dee260dca2c9
Reviewed-on: https://chromium-review.googlesource.com/747272
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49056}
Takes too long on bots to run
Bug:
Change-Id: Ia99717fe943ff6437497425abd3a3cb9999d7564
Reviewed-on: https://chromium-review.googlesource.com/746533
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#49055}
This adds support to the KeyedLoadIC to ignore out of bounds accesses
for Strings and return undefined instead. We add a dedicated bit to the
Smi handler to encode the OOB state and have TurboFan generate appropriate
code for that case as well. This is mostly useful when programs
accidentially access past the length of a string, which was observed and
fixed for example in Babel recently, see
https://github.com/babel/babel/pull/6589
for details. The idea is to also extend this mechanism to Arrays and
maybe other receivers, as reading beyond the length is also often used
in jQuery and other popular libraries.
Note that this is considered a mitigation for a performance cliff and
not a general optimization of OOB accesses. These should still be
avoided and handled properly instead.
This seems to further improve the babel test on the web-tooling-benchmark
by around 1%, because the OOB access no longer turns the otherwise
MONOMORPHIC access into MEGAMORPHIC state.
Bug: v8:6936, v8:7014
Change-Id: I9df03304e056d7001a65da8e9621119f8e9bb55b
Reviewed-on: https://chromium-review.googlesource.com/744022
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49049}
Following up on adding n-ary nodes, this extends the parser and
interpreter to support n-ary logical operations.
Bug: v8:6964
Bug: chromium:731861
Change-Id: Ife2141c389b9abccd917ab2aaddf399c436ef777
Reviewed-on: https://chromium-review.googlesource.com/735497
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49029}
Instead of creating a runtime call for the static class field
initializer in the AST, we do it in the bytecode generator.
This adds the initializer function to the ClassLiteral AST node.
Bug: v8:5367
Change-Id: Iffaa6531511023812011ee19fc96cea9e5c9d3f3
Reviewed-on: https://chromium-review.googlesource.com/736315
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49008}
The status-file flags and the flags from the test case's source code
must always overwrite extra flags set by bots.
Bug: v8:6924
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I0e2aabb69da7cfb8ba6c1c79bd3851462071a6ac
Reviewed-on: https://chromium-review.googlesource.com/732656
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49001}
Because this test uses heap verification, it is quite slow. Split it
into 4 smaller tests to avoid test timeout and allow them to be run
in parallel.
R=ahaas@chromium.org
Bug:
Change-Id: Ie4ac841d1d8215019bb5cfcc335daea6b10ab789
Reviewed-on: https://chromium-review.googlesource.com/738146
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48998}
This adds two tests to verify that the --liftoff flag has the indented
effect, and that Liftoff compilation is off by default.
R=titzer@chromium.org
Bug: v8:6600
Change-Id: Ie7e13184b5068f572b78dbdf7abbcded6d859fc5
Reviewed-on: https://chromium-review.googlesource.com/733561
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48995}
We now represent the SameValue operation explicitly in TurboFan and the
operation can thus participate in all kinds of optimizations. Especially
we get rid of the JSCall node in the general case, which blocks several
optimizations across the call. The general, baseline performance is now
always on par with StrictEqual.
Once the StrictEqual operator is also a simplified operator, we should
start unifying the type based optimizations in SimplifiedLowering.
In the micro-benchmark we go from
testStrictEqual: 1422 ms.
testObjectIs: 1520 ms.
testManualSameValue: 1759 ms.
to
testStrictEqual: 1426 ms.
testObjectIs: 1357 ms.
testManualSameValue: 1766 ms.
which gives the expected result.
Bug: v8:7007
Change-Id: I0de3ff6ff6209ab4c3edb69de6a16e387295a9c8
Reviewed-on: https://chromium-review.googlesource.com/741228
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48994}
... and use them to complete the BigInt function.
Bug: v8:6791
Change-Id: Ia36db86b92d1a0cfcb783516e04d6c0e3750f194
Reviewed-on: https://chromium-review.googlesource.com/737643
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48993}
We can already construct wrapper objects using Object().
R=jkummerow@chromium.org
Bug: v8:6791
Change-Id: Ic4079654ef1fcae2be4b588cb12c2645e199f4f7
Reviewed-on: https://chromium-review.googlesource.com/738089
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48955}
Abstract equality comparison of a BigInt and a String converts the
latter to BigInt. This conversion can fail; since we do not want to
pass a context to the comparison function, we must signal such failure
without throwing an exception.
This CL uses the existing ShouldThrow enum to configure behavior of
String-to-BigInt conversion, moving it out of Object into globals.h.
Bug: v8:6791, v8:6979
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ibb98675079b8392cf03bbcbbbd5556108500a32d
Reviewed-on: https://chromium-review.googlesource.com/734172
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48946}
This flag has been on by default since Chrome 61.
Bug: v8:5549
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I81c34d1d3a7dbd219acce2cdf0cf4917eb484002
Reviewed-on: https://chromium-review.googlesource.com/738312
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48945}
and use a newly-introduced "enum class Operation" in all
other places that so far passed Token::Values around.
Also delete some related dead code along the way.
Bug: v8:6921
Change-Id: I062f396d304aa62298cfeff202e3132a4a5597c1
Reviewed-on: https://chromium-review.googlesource.com/736851
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48944}
It's been on by default since Chrome 61.
Bug: v8:4806
Change-Id: I748d9008d29997667458649d7bf4999e15ff8615
Reviewed-on: https://chromium-review.googlesource.com/737416
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48943}
We have an internal limit of 50000 local variables per wasm function.
This limit is checked when decoding the function body. For asm.js, we
skip function body validation, since by construction the code we
generate is correct. This makes us fail unexpectedly when trying to
(lazily) compile an asm.js function with more than 50000 locals.
Hence, check this limit in the asm parser and bail out if it is
exceeded.
R=mstarzinger@chromium.org
Bug: chromium:775710
Change-Id: I89d2069e133fb0f84947d477ae1ac5eda85571aa
Reviewed-on: https://chromium-review.googlesource.com/732660
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48929}
There is no need to test each operation on each single memory location.
R=titzer@chromium.org, binji@chromium.org
Bug: v8:6994
Change-Id: Ib401fa1dd4db2e1b9c7ee0b48bb0c1cc9e3f9139
Reviewed-on: https://chromium-review.googlesource.com/735149
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48921}
Expressions of the form
a_0 + a_1 + a_2 + a_3 + ... + a_n
seem to be reasonably common for cases such as building templates.
However, parsing these expressions results in a n-deep expression tree:
...
/
+
/ \
+ a_2
/ \
a_0 a_1
Traversing this tree during compilation can cause a stack overflow when n is
large.
Instead, for left-associate operations such as add, we now build up an
n-ary node in the parse tree, of the form
n-ary +
/ | \
/ | ... \
a_0 a_1 a_n
The bytecode compiler can now iterate through the child expressions
rather than recursing.
This patch only supports arithmetic operations -- subsequent patches
will enable the same optimization for logical tests and comma
expressions.
Bug: v8:6964
Bug: chromium:724961
Bug: chromium:731861
Bug: chromium:752081
Bug: chromium:771653
Bug: chromium:777302
Change-Id: Ie97e4ce42506fe62a7bc4ffbdaa90a9f698352cb
Reviewed-on: https://chromium-review.googlesource.com/733120
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48920}
We were already handling the case that a called import throws, but if
it returned an error which is not convertible to a number, we failed
with a CHECK error.
This CL fixes this.
R=titzer@chromium.org
Bug: chromium:771970
Change-Id: I6c9983459109d49c43304610b696d49de986a250
Reviewed-on: https://chromium-review.googlesource.com/735354
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48912}
This optimization was disabled because 32-bit builds didn't properly
find certain integer keys in maps anymore. The reason was that the
runtime wasn't using ComputeIntegerHash for the full Signed32 range,
but only for the SignedSmall range.
This change improves the ARES-6 Basic test by around 6-7% on the steady
state.
Bug: chromium:77459, v8:6410, v8:6354, v8:6278, v8:6344
Change-Id: Ifae64e6b23ca8acee4c792be299f64caf951242f
Reviewed-on: https://chromium-review.googlesource.com/737871
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48905}
Only rewind destructuring assignments if we actually preparsed
the arrow function. For the case of single-expression bodies,
we don't preparse, but we were previously erroneously rewinding.
Bug: v8:6970
Change-Id: I38e15a8a5bdb05abee3bafe7bbd7736b55a6950b
Reviewed-on: https://chromium-review.googlesource.com/733950
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48883}
... mainly by adapting Object::Compare and
CodeStubAssembler::RelationalComparison.
TBR=rmcilroy@chromium.org
Change-Id: I34448d45b4950b9318263c4a667aa9db7d77232d
Bug: v8:6791
Reviewed-on: https://chromium-review.googlesource.com/730730
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48873}
When lowering a monomorphic load/store, where multiple receiver maps
have been recorded, but the action to be performed is the same (i.e.
yielding undefined because the property is not found), TurboFan used
to ignore the Smi case, leading to a pretty terrible deoptimization
loop, as the LOAD_IC/STORE_IC properly recorded that state and thus
didn't change it's state.
Fixing this issue gives a 18-20% boost on the prettier test of the
web-tooling-benchmark, which was suffering a lot from this problem.
Bug: v8:6936, v8:6991
Change-Id: Id208ec7129a7f6b190d989bda31f936040393226
Reviewed-on: https://chromium-review.googlesource.com/735342
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48865}
The (KEYED_)LOAD/STORE_ICs didn't properly leave the UNINITIALIZED as
long as the receiver was always null/undefined. This leads to
deoptimization loops in TurboFan, because the compiler always put in a
SOFT deoptimization at this point.
Bug: v8:6989
Change-Id: I1a32bfb722f121f8b593e8972e657290d7b0531d
Reviewed-on: https://chromium-review.googlesource.com/735319
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48854}
Previously, V8's slice was implemented in a combination of C++ and a
Javascript fallback. The disadvantage of this approach was that the
fast-path required a call through the CEntryStub, which introduced
considerable overhead for small arrays with fast elements kinds.
Now the implementation primarily uses the CSA to generate both the
full spec-complaint implementation as well as fast paths for argument
objects and arrays with fast elements kinds. The CSA implementation
uses a C++ implementation fallback in select situations where the the
complexity of a CSA implementation would be too great and the
CEntryStub overhead is not decisive (e.g. slices of dictionary
elements arrays).
Performance results on semi-random arrays with small number of
elements (old vs. new):
smi copy: 48.7 ms vs. 12 ms
smi slice: 43.5 ms 14.8 ms
object copy: 35.5 ms 7.7 ms
object slice: 38.7 ms 8.8 ms
dictionary slice: 2398.3 ms vs. 5.4 ms
fast sloppy arguments slice: 9.6 ms vs. 7.2 ms
slow sloppy arguments slice: 28.9 ms vs. 8.5 ms
As a bonus, the new implementation is fully spec-compliant and fixes
at least one existing bug.
The design document for Array.prototype builtin rework can be found
at https://goo.gl/wFHe2n
Bug: v8:1956,v8:6601,v8:6710,v8:6978
Change-Id: Ia0155bedcf39b4577605ff754f416c2af938efb7
Reviewed-on: https://chromium-review.googlesource.com/574710
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48853}
