This CL fixes a bug where execution would continue on a fast-path
even though a previous recursion step bailed to the slow path. This
would allow possibly illegal loads that could leak to JS.
Drive-by change: Instead of bailing to the slow-path on each recursion
step, we now bail completely and start the slow-path afterwards.
R=cbruni@chromium.org, jgruber@chromium.org
Bug: chromium:854299, v8:7382
Change-Id: Ib2fd5d85dbd0c3894d7775c4f62e053c31b5e5d1
Reviewed-on: https://chromium-review.googlesource.com/1107702
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53892}
This CL fixes a bug that allowed OOB read/stores on fastpaths when
a comparison function caused the underlying FixedArray to change
while keeping the elements kinds and size property on the original
JSArray the same.
R=jgruber@chromium.org
Bug: chromium:852592
Change-Id: I09af357d10e7f41e75241e4c87430fc9aa806f8c
Reviewed-on: https://chromium-review.googlesource.com/1104158
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53811}
Reading up on the bug description, this is a test
that is triggered by TurboFan execution. This can
be done with natives and does not need excessive
loop iterations. Additionally, we have a more specific
regression test for the original issue in the repo:
http://crrev.com/c/584837
Bug: v8:7783
Change-Id: Id022b515b663e6fb897acb29f43ef92b70b547b8
Reviewed-on: https://chromium-review.googlesource.com/1101018
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53799}
Byte offset can be outside of Smi range and must be loaded as a Number
rather than a Smi.
Bug: chromium:852258
Change-Id: Ida6e07ba68a050d4f5a9f28500986cc67c619b4c
Reviewed-on: https://chromium-review.googlesource.com/1100886
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53748}
`date` could be outside the int32_t range and thus FastD2I may not be
used.
Bug: chromium:849663
Change-Id: I96a012b40d35ec8f80e449e4e687b0ce7b572d5e
Reviewed-on: https://chromium-review.googlesource.com/1087063
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53526}
Compress the parameter count (and function length) stored in
SharedFunctionInfo to a uint16_t. This limits us to 2^16 - 1 parameters
per function, minus one for the "don't adapt arguments" sentinel value,
which is one fewer than Code::kMaxArguments was already. Anyway, 65534
arguments should be enough for anyone!
This drops SFI size by 4 bytes.
Bug: chromium:818642
Change-Id: I126bfb24453dcdc5087a104d3a12cf195a56fa9f
Reviewed-on: https://chromium-review.googlesource.com/1076627
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53447}
The regression test 2185-2 measured the Array.p.sort time for various
pre-sorted data configurations. This CL adds the various data
configurations to the ArraySortPreSorted benchmark and removes the
regression test altogether.
R=cbruni@chromium.org, jgruber@chromium.org
Change-Id: I6e2eb235e4a7578f4a107229bfc6a9e89a3aa5e3
Reviewed-on: https://chromium-review.googlesource.com/1076188
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53420}
This loads references to {null} values from the instance object instead
of embedding them into the generated code. It is one step towards making
the {WasmCode} objects independent of the Isolate.
Note that this also fixes an issue with the serializer/deserializer that
failed to properly serialize {null} values and accidentally collapsed
them to {undefined} values instead.
R=ahaas@chromium.org
TEST=mjsunit/regress/wasm/regress-7785
BUG=v8:7424,v8:7785
Change-Id: Ie436c2d96890e7c8c89ffe2bd4189a759254775b
Reviewed-on: https://chromium-review.googlesource.com/1070981
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53352}
At the moment, WebAssembly.instantiate(bytes) is implemented by
desugaring it to WebAssembly.compile(bytes).then(WebAssembly.instantiate).
The problem is that the {then} in this snippet is observable. With this
CL I introduce a CompilationResultResolver which allows to do the
desugaring internally and thereby make the {then} unobservable.
Unfortunately the result of WebAssembly.instantiate(bytes) is different
than the result of WebAssembly.instantiate(module). Therefore I also
introduced an InstantiationResultResolver for symmetry with
WebAssembly.compile.
R=mstarzinger@chromium.org
Bug: chromium:837417
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I2d98e03d65f2ada19041d5a9e2df5da91b24ccca
Reviewed-on: https://chromium-review.googlesource.com/1059783
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53347}
Instead use the canonical empty fixed array. Some code assumes
that this is the only fixed array of length 0.
Bug: chromium:843062
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: If780acf50147c061a81f2ff2b31779fbd1c78559
Reviewed-on: https://chromium-review.googlesource.com/1064052
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53320}
This is not web compatible, so let's delete the code.
Bug: v8:5536
Change-Id: I50506d37dcdff1f7f95577c47adcec653cc1f06e
Reviewed-on: https://chromium-review.googlesource.com/1064740
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53264}
The js-to-wasm wrappers are shared across instances, so we cannot
directly call the instance-specific wasm-to-js wrappers. Instead, we
need to call via the import table.
R=titzer@chromium.org
Bug: chromium:843563
Change-Id: Ia882604f6769472fe2eb69176cbed728215ced29
Reviewed-on: https://chromium-review.googlesource.com/1064610
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53254}
It is possible for user code to modify fast regexp result objects
before they are used e.g. by RegExp.p.match, so we may not make any
assumptions about their contents. The only exception is when the
RegExp itself is fast.
Bug: chromium:843022
Change-Id: I14eafbdfb2b2ced609da1391b57c73cbe167f7fb
Reviewed-on: https://chromium-review.googlesource.com/1061455
Reviewed-by: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53210}
Array.indexOf accepts an optional fromIndex argument. When non-negative,
this argument restricts the searched indices to those starting at
fromIndex:
[1, 2, 1].indexOf(1,1) == 2
When negative, it is meant to be added to the array length to provide
such initial index for the search:
[1, 2, 1].indexOf(1, -2) == 2
This transformation has been done by the non-optimised builtin but not
by the reducer. The CL adds this construction to the reducer.
Bug: chromium:842612
Change-Id: I0ff089997f4ebb4dc3c2923e52c382a8a96cd711
Reviewed-on: https://chromium-review.googlesource.com/1059628
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Vaclav Brozek <vabr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53197}
The clusterfuzz issue crashes because VisitBinops expected only but 4
input operands but in the generated graph 5 input operands get created
The issue is fixed by increasing the size of the input operand buffer.
R=jarin@chromium.org
Bug: chromium:842501
Change-Id: I4bbb09a968e165e6f5a0a02d06eee97333f7aa38
Reviewed-on: https://chromium-review.googlesource.com/1056989
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53147}
We must not accept something of kBit representation as of
kWord32 representation (unless it's truncated accordingly).
Deopt instead.
Bug: v8:7740
Change-Id: Ib4f73600d66f8762a6e22f7ea1ce79e8ef451b34
Reviewed-on: https://chromium-review.googlesource.com/1054670
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53144}
This was already the case for 1-byte strings. This prevents crashes when
attempting to externalize such strings.
Bug: chromium:842078, v8:7464
Change-Id: I3092a6748edaf77b2689f7b6f6b949929998e508
Reviewed-on: https://chromium-review.googlesource.com/1054290
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53124}
Avoid writing NumberOfElements to HashTable when it hasn't changed as
the HashTable could be in RO_SPACE and this operation will crash.
Bug: v8:841592
Change-Id: Iffadd567fc10aa9cd13d953da81275464b16c6c0
Reviewed-on: https://chromium-review.googlesource.com/1052693
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53116}
This is a reland of e084eea628.
Undefined behavious was fixed in https://crrev.com/c/1051235.
Original change's description:
> Fix SourcePositionInfo for wasm
>
> In wasm we often don't have a SharedFunctionInfo associated with a
> compilation job, so we can't get a Script. Just print "unknown" in
> these cases (instead of crashing).
>
> R=titzer@chromium.org
> CC=herhut@chromium.org
>
> Bug: chromium:840757, v8:7738
> Change-Id: I850c6adfd9e07c9a0f6dd018f1a9314feb89d887
> Reviewed-on: https://chromium-review.googlesource.com/1049632
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#53080}
TBR=titzer@chromium.org
Bug: chromium:840757, v8:7738
Change-Id: If04040a33766955cfed78e7c27226dd04c3f9b9f
Reviewed-on: https://chromium-review.googlesource.com/1051266
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53111}
Plus a bit of CSA typification.
Bug: v8:7725
Change-Id: I43fea4a4c0739f9c24d84035816b046e742372ee
Reviewed-on: https://chromium-review.googlesource.com/1051653
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53102}
This reverts commit e084eea628.
Reason for revert:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20UBSanVptr/builds/3163
Original change's description:
> Fix SourcePositionInfo for wasm
>
> In wasm we often don't have a SharedFunctionInfo associated with a
> compilation job, so we can't get a Script. Just print "unknown" in
> these cases (instead of crashing).
>
> R=titzer@chromium.org
> CC=herhut@chromium.org
>
> Bug: chromium:840757, v8:7738
> Change-Id: I850c6adfd9e07c9a0f6dd018f1a9314feb89d887
> Reviewed-on: https://chromium-review.googlesource.com/1049632
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#53080}
TBR=titzer@chromium.org,clemensh@chromium.org
Change-Id: Ib2020ea3f2b778df9fe50ccbe803938f2f4fd709
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:840757, v8:7738
Reviewed-on: https://chromium-review.googlesource.com/1051265
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53082}
In wasm we often don't have a SharedFunctionInfo associated with a
compilation job, so we can't get a Script. Just print "unknown" in
these cases (instead of crashing).
R=titzer@chromium.org
CC=herhut@chromium.org
Bug: chromium:840757, v8:7738
Change-Id: I850c6adfd9e07c9a0f6dd018f1a9314feb89d887
Reviewed-on: https://chromium-review.googlesource.com/1049632
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53080}
This CL implements the functionality of SafeRemoveArrayHoles (JS),
which is used as a pre-processing step for sorting, in a runtime
function.
SafeRemoveArrayHoles is a generic fallback, when an existing runtime
function fails to remove holes/move undefineds to the end of an array.
This CL extends the existing runtime function to also support JSProxy
objects, and objects where indices have accessors.
R=cbruni@chromium.org, jgruber@chromium.org
Bug: v8:7382
Change-Id: I4881539cf2171caba08ff6e3e50320291f49839c
Reviewed-on: https://chromium-review.googlesource.com/1041950
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53060}
Since 94ce16b704, when loading an iterator from null or undefined, we
generate the error message "x is not iterable" instead of the unwieldy
"Cannot read property 'Symbol(Symbol.iterator)' of undefined". However
Runtime::GetObjectProperty, which is used as slow path by LoadICs, did
not check for this case, leading to different messages being generated
depending on IC state.
Bug: chromium:823130
Change-Id: Ie98500b97efef401aac9880b9af47d58c3c2825d
Reviewed-on: https://chromium-review.googlesource.com/1042951
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52974}
We incorrectly used a TurboFan typer check for {0,10,undefined} on the
radix argument on Number.parseInt, which was internally widened to the
checking whether radix is in range 0-10 or undefined. This CL introduces
two separate checks.
Bug: chromium:838766
Change-Id: I5ebfc1c82bad5b9794b4f844e79e4df01f541a83
Reviewed-on: https://chromium-review.googlesource.com/1039197
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52914}
A stack overflow can be thrown by JSEntryStub, which means the
thread-in-wasm flag will not have the expected value. To accommodate
this, we now clear the flag during exceptional returns if it is set.
Bug: chromium:834624
Change-Id: I8359af79886ab98dfecc2fb39ca19118b7fa38eb
Reviewed-on: https://chromium-review.googlesource.com/1019570
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52891}
When WebAssembly.instantiate or WebAssembly.instantiateStreaming is
called in JavaScript, internally we transfrom it into
WebAssembly.compile(buffer).then(WebAssembly.instantiate). However,
modifying the prototype of WebAssembly.Module can change the result of
WebAssembly.compile(buffer). With this CL we make sure that even if the
result of WebAssembly.compile is modified, there is still no type
confusion. In the long term we have to do a refactoring and remove
this internal transformation.
R=mstarzinger@chromium.org
Bug: chromium:837417
Change-Id: I376068b8b8b01b991ec450162da6a62ae7030c62
Reviewed-on: https://chromium-review.googlesource.com/1032392
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52859}
In the case of an indirect call to an imported function, the target
instance stored in the IFT was actually wrong.
Bug: chromium:834619
Change-Id: Id2ac4158335ecf2b58e1983ce37df852a9ebd1b2
Reviewed-on: https://chromium-review.googlesource.com/1030174
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52831}
WebAssembly.instantiate is polymorphic, it can either take a module
object as parameter, or a buffer source which should be compiled first.
To share code between the two implementations, the module object was
first passed to a promise (i.e. which is the result of compilation).
However, passing the module object to a promise has a side effect if
the module object has a then function. To avoid this side effect I
remove this code sharing and call AsyncInstantiate directly in case
the parameter is a module object.
R=mstarzinger@chromium.org
Bug: chromium:836141
Change-Id: I67b76d0d7761c5aeb2cf1deda45b6842e494eed4
Reviewed-on: https://chromium-review.googlesource.com/1025774
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52755}
Several functions on Array.prototype incorrectly threw a TypeError just
because their receiver was sealed or frozen.
Bug: v8:7677
Change-Id: I4ec38bfbf468f9bd676f1c0b341c8a50cf814f15
Reviewed-on: https://chromium-review.googlesource.com/1021870
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52718}
With certain ICU data bundles (such as the Node.js "small-icu"),
%GetDefaultICULocale() may return a more specific language tag (e.g.
"en-US") than what's available (e.g. "en"). In those cases, consider the
more specific language tag supported.
This CL also resolves the following Node.js issue:
https://github.com/nodejs/node/issues/15223
Bug: v8:7024
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ifda0776b3418734d5caa8af4e50c17cda95add73
Reviewed-on: https://chromium-review.googlesource.com/668350
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52716}
Throw a TypeError if the length of a concat-spreadable object makes the
total length too large, as specified.
Bug: v8:7652
Change-Id: Ie3f694d64c949703edd733c0310cfb3f64b78a15
Reviewed-on: https://chromium-review.googlesource.com/1013714
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52644}
If the new length is too large, we must throw a TypeError.
Bug: v8:7652
Change-Id: I47268c04405f7a5f5bbc971cd434f2d786af9ca1
Reviewed-on: https://chromium-review.googlesource.com/1013563
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52624}
This patch moves the desugaring from the parser to the bytecode
generator for super calls that have a spread at a non last position.
This allows us to have the post super() call behavior, such as
initializing instance fields in one place in VisitCallSuper.
Bug: v8:7642
Change-Id: I00a693beb7078a63282359c1121b66bb62c157c8
Reviewed-on: https://chromium-review.googlesource.com/1009907
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52596}
It is not safe to assume the first match is a string just
because the RegExp result is fast.
Bug: chromium:831943
Change-Id: Idd40f8b75312f0be54f45f626dc017339033abc6
Reviewed-on: https://chromium-review.googlesource.com/1009325
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Cr-Commit-Position: refs/heads/master@{#52578}
On indirect function calls, if the corresponding table entry is empty,
we cannot call {GetCodeFromStartAddress}. In that case, the signature
check will fail anyway, so perform the signature check first, and only
get the code object if the check succeeds.
R=mstarzinger@chromium.org
Bug: chromium:831463
Change-Id: Iead949e4c12502b1a2a3949db2dabab4a184a1e7
Reviewed-on: https://chromium-review.googlesource.com/1005005
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52542}
We hardcoded this accidentally in the original CL for the turbofan case,
instead we need to call JSConstructStubGeneric() which will return the
correct construct stub based on the harmony_restrict_constructor_return
flag.
Bug: chromium:829899
Change-Id: I6776a5daebd57d8881d926ad68595141312a877d
Reviewed-on: https://chromium-review.googlesource.com/1001893
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52470}
The bug was fixed in https://crrev.com/c/995796, but this CL adds a
regression test to make sure it stays fixed.
Bug: chromium:827806
Change-Id: I9f4aed364bbd310af4253da457887a8b8015533a
Reviewed-on: https://chromium-review.googlesource.com/993237
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52409}
This is a follow-up to https://chromium-review.googlesource.com/981687.
When a wasm function has a large stack frame, the x64 code generator
performs the stack overflow check before constructing the frame. This
requires the use of the `address_of_real_stack_limit` external
reference.
This reference is thread local, so if it is not relocated the stack
overflow check will always fail.
Bug: chromium:808848
Change-Id: I0edf3fe5a006242fc50d0bff44cd9dd0e7d85bd9
Reviewed-on: https://chromium-review.googlesource.com/982906
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52330}
When peeking into descriptor arrays (for Function.prototype.bind
inlining), we need to check the number of descriptors rather than
the length of the DescriptorArray.
Bug: chromium:825045
Change-Id: I55dbe1544e5e4cb8e23d873961c71ed12294d89c
Reviewed-on: https://chromium-review.googlesource.com/991812
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52315}
When a wasm function has a large stack frame, the x64 code generator
performs the stack overflow check before constructing the frame. This
requires using the `address_of_real_stack_limit` external reference, as
well as the `ThrowWasmStackOverflow` runtime function.
`ThrowWasmStackOverflow` is called via a generated trampoline, but it is
not a builtin, so the serializer adds it to the `stub_lookup_` map. This
map is encoded by using a monotonically increasing `stub_id` that starts
at 0.
When the function is serialized, a stub is differentiated from a builtin
by which half of the `i32` bits is used, upper or lower. A stub only
uses the lower 16 bits and a builtin only uses the upper 16 bits.
The deserializer checks whether the lower 16 bits are 0; if so, it is
determined to be a builtin. But if the `stub_id` is 0, then it will be
confused with builtin 0 (`RecordWrite`). Calling the builtin instead of
the stub causes a crash.
This CL starts all `stub_id`s at 1, which prevents the builtin/stub
confusion.
There is an additional bug that is not fixed by this CL:
`ThrowWasmStackOverflow` shouldn't be called at all. Currently it is
called because `address_of_real_stack_limit` is a thread-local value
that is not properly relocated.
Bug: chromium:808848
Change-Id: I06b3e650ea58ad717dcc47a3716443e16582e711
Reviewed-on: https://chromium-review.googlesource.com/981687
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52252}
--cleanup-code-caches-at-gc flag was removed in
b8b25e1c27,
rendering the test obsolete.
Change-Id: I34331d230102924899c89d3330379df51a489029
Reviewed-on: https://chromium-review.googlesource.com/980937
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52239}
This eases transition handlers caching and avoids memory overhead of
respective StoreHandler objects. In addition, it allows to use such
transition handlers on runtime side to make Object.assign implementation
a bit faster.
Bug: v8:5988
Change-Id: Iba660a11d4b300cd5f80615fb7e2608e53da8fee
Reviewed-on: https://chromium-review.googlesource.com/931701
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52187}
When using trap handlers, memory references do not get any checks inserted. This
means there is no check for a null memory as happens when the memory size is
0. Normally this would be correctly caught as an out of bounds access, since the
low memory addresses are not normally mapped. However, if they were mapped for
some reason, we would not catch the out of bounds access.
The fix is to ensure WebAssembly instances always have a guard region even if
the memory is size 0.
This is a rewrite of 5e76ff5a4a
Note that this can lead to a large amount of unnecessary address space usage,
so we share a single reservation for empty array buffers.
Bug: chromium:769637
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: Ia8e84be6d595e347d3d342959f2c374db1a3f683
Reviewed-on: https://chromium-review.googlesource.com/702657
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52163}
On float comparisons, we need a scratch byte register for the setcc
instruction, and if none is available, we spill. But this spilling code
is skipped if one of the operands is NaN. The cache state is updated
however, so following code assumes that the spill happened.
This CL fixes this by spilling before checking for NaN, such that the
spilling code is always executed.
R=titzer@chromium.org
Bug: v8:7582, v8:6600
Change-Id: I768d8de14e494d3ebea181c1f9f3129a4b005396
Reviewed-on: https://chromium-review.googlesource.com/973961
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52162}
See referenced bug: Async compilation can deadlock if a background task
queues the last compilation unit to be finished while the finisher
is already exiting because there was no more work.
This CL fixes this by making the finisher task check for new work after
setting the finisher_is_running_ flag to false.
R=ahaas@chromium.orgCC=kimanh@google.com
Bug: chromium:824681
Change-Id: If1f5700a9fdd5d150b36e37a5d14b692c2b0f3fb
Reviewed-on: https://chromium-review.googlesource.com/975301
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52139}
On ia32, the upper "half stack slot" must be located above the lower
half stack slot (in absolute address), hence the index is
"2 * index - 1" instead of "2 * index + 1". Note that the index
describes the negative offset from the stack pointer.
R=titzer@chromium.org
Bug: v8:7579
Change-Id: If207af405b126ab30043432d7934273e6e2a5330
Reviewed-on: https://chromium-review.googlesource.com/973301
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52116}
This avoids a deopt loop.
Bug: v8:7254
Change-Id: I3a676186bc52fd47b03f03c26cb07d9257993693
Reviewed-on: https://chromium-review.googlesource.com/968503
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52036}
This reverts commit c94dcb2117.
Reason for revert: several performances regressions.
Original change's description:
> [compiler] Don't infer receiver maps for stores.
>
> This avoids a deopt loop.
>
> Bug: v8:7254
> Change-Id: I9ab1dfc754c5ad63c451a9e2276aa1d7eb4c27b1
> Reviewed-on: https://chromium-review.googlesource.com/966065
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#51994}
TBR=jarin@chromium.org,neis@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:7254
Change-Id: Iff9c6fb61a559e48ad11d2db9e559de61cc0f5ef
Reviewed-on: https://chromium-review.googlesource.com/968302
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52012}
This avoids a deopt loop.
Bug: v8:7254
Change-Id: I9ab1dfc754c5ad63c451a9e2276aa1d7eb4c27b1
Reviewed-on: https://chromium-review.googlesource.com/966065
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51994}
There was a bug in spilling i64 constants, in that the half stack slot
*above* should have been filled with the high word instead of the one *below*.
Instead of just fixing this, this CL optimizes spilling x64 constants to the
stack by emitting shorter and faster code, especially if the constant fits in
31 bits (which is the majority of cases).
R=titzer@chromium.org
Bug: v8:7565,v8:6600
Change-Id: Id75ddafe82615930a84333a0c49bd515ccbcc093
Reviewed-on: https://chromium-review.googlesource.com/965062
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51985}
TurboFan assumed that the output of NumberToString is always a
sequential string, since that's what we put into the number to
string table. However we might eventually morph these strings
into ThinStrings when we need to internalize them, in which case
the type in TurboFan will be wrong, and we read out of bounds.
Also-By: tebbi@chromium.org
Bug: chromium:822284
Change-Id: I5aebe73028b95849fff72bba262c517677112353
Reviewed-on: https://chromium-review.googlesource.com/964523
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51970}
Always use the runtime to set the length on an array if it doesn't match
the expected length after populating it using Array.from.
Bug: chromium:821137
Change-Id: I5a730db58de61ba789040e6dfc815d6067fbae64
Reviewed-on: https://chromium-review.googlesource.com/962222
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51919}
During a C call, a previous value of the stack pointer is stored in a
platform specific callee saved register. Loading the out argument of the
C call might overwrite the value in that register, if the destination
register collides with the platform specific register. Hence, do first
use that register to restore the previous stack pointer, and only then
load the out argument.
Similarly, when pushing arguments to the stack, do first push all
values and then set the platform specific register in order to avoid
overwriting an argument value held in that register.
Drive-by: Fix offset computations for parameters pushed to the stack
for c calls.
R=titzer@chromium.org
Bug: chromium:820802,chromium:820896,chromium:820807,v8:6600
Change-Id: If4567467b7912454f0bd2cad5927233c98894b03
Reviewed-on: https://chromium-review.googlesource.com/959064
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51916}
The IterableToList helper builtin can return the input JSArray unchanged
if the fast-path detection decides that it doesn't need to iterate the
elements, which means we can also get a JSArray with an elements kind
that is not PACKED_ELEMENTS as a result of IterableToList.
Bug: chromium:821159, v8:7310
Change-Id: I93a886e6b7f1e1a58dd05affa46fea7501cc5a81
Reviewed-on: https://chromium-review.googlesource.com/959323
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51893}
Depending on visitation order the LoadElimination might be find memoized
nodes in its state tables that were killed by other reducers in the mean
time. The LoadElimination must just ignore those stale entries.
Bug: chromium:820820
Change-Id: Ia62e401ff77da547ed215a14074e70aeb5c3a766
Reviewed-on: https://chromium-review.googlesource.com/958843
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51892}
The lifetime of the collator is handled by the JavaScript heap. At the
moment this is implemented with a weak GlobalHandle. With this CL I
change the implementation to use a Managed object instead. In addition I
did some code cleanup.
The main reason for using a Managed is an lsan problem. The final GC in
d8 is triggered before all pending WebAssembly compilations get
canceled. Via the native context, WebAssembly compilation can keep the
Collator wrapper alive, and therefore the collator is never deallocated.
Managed, however, get processed at isolate teardown, independent of the
reachability of the Managed.
TEST=mjsunit/regress/regress-813440
Bug: chromium:813440
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ie727eb1aff2144586eb36426cc44a32357c0f822
Reviewed-on: https://chromium-review.googlesource.com/956069
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51886}
On 32-bit systems, the computation {count + type_list->size()} can
overflow, leading to memory corruption later on.
R=titzer@chromium.org
Bug: chromium:819869
Change-Id: Ic81d201e58211e3989b4e945cd52e98dc951fbda
Reviewed-on: https://chromium-review.googlesource.com/955025
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51817}
When optimizing SpeculativeToNumber we need to pay attention to the
hint, otherwise we optimize away a Signed32 conversion, based on the
fact that the input is a Number.
Bug: chromium:819298
Change-Id: I2ac7b0dac708fee9083eca2880bd5674a82daaa3
Reviewed-on: https://chromium-review.googlesource.com/955423
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51805}
The optimized code for %ArrayIteratorPrototype%.next for holey arrays
was wrong, since it would first store the [[NextIndex]] and then check
whether it hit a hole. However in that case TurboFan doesn't have any
point to deoptimize to, so we need to perform the side-effecting stores
only after all checks are done.
Bug: v8:7510, v8:7514, chromium:819086
Change-Id: I0214c7124833286113e4dc7403ddc20a82fa8da3
Reviewed-on: https://chromium-review.googlesource.com/950723
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51753}
Math fast-path cannot drop arguments because their side-effects
must be preserved. For example, Math.imul(x) dropped x entirely,
because if x is convertible to an integer, the result is 0.
This, however, is not OK because converting x to an integer might
throw.
Bug: chromium:818070, v8:7250, v8:7240
Change-Id: I8363e6dcd3fc78c879395aacb636d5782c3b023e
Reviewed-on: https://chromium-review.googlesource.com/948523
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51736}
This changes the JSArrayIterator to always have only a single instance
type, instead of the zoo of instance types that we had before, and
which became less useful with the specification update to when "next"
is loaded from the iterator now. This greatly simplifies the baseline
implementation of the array iterator, which now only looks at the
iterated object during %ArrayIteratorPrototype%.next invocations.
In TurboFan we introduce a new JSCreateArrayIterator operator, that
holds the IterationKind and get's the iterated object as input. When
optimizing %ArrayIteratorPrototype%.next in the JSCallReducer, we
check whether the receiver is a JSCreateArrayIterator, and if so,
we try to infer maps for the iterated object from there. If we find
any, we speculatively assume that these won't have changed during
iteration (as we did before with the previous approach), and generate
fast code for both JSArray and JSTypedArray iteration.
Drive-by-fix: Drop the fast_array_iteration protector, it's not
necessary anymore since we have the deoptimization guard bit in
the JSCallReducer now.
This addresses the performance cliff noticed in webpack 4. The minimal
repro on the tracking bug goes from
console.timeEnd: mono, 124.773000
console.timeEnd: poly, 670.353000
to
console.timeEnd: mono, 118.709000
console.timeEnd: poly, 141.393000
so that's a 4.7x improvement.
Also make presubmit happy by adding the missing #undef's.
Bug: v8:7510, v7:7514
Change-Id: I79a46bfa2cd0f0710e09365ef72519b1bbb667b5
Reviewed-on: https://chromium-review.googlesource.com/946098
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51725}
The CHECK didn't account for the recent introduction of
StoreInArrayLiteralIC.
Bug: v8:5940, chromium:818438
Change-Id: I73b4120eb39b16d766f0b1a9cb82ba44804b09a3
Reviewed-on: https://chromium-review.googlesource.com/947950
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51719}
Table inits can contain imported functions, hence their code will be a
wasm-to-wasm wrapper.
Fix a DCHECK and add a regression test.
R=ahaas@chromium.org
Bug: chromium:817380
Change-Id: I836be589e1ae66839ccd470154c8dea488e6bc1f
Reviewed-on: https://chromium-review.googlesource.com/943107
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51685}
The assert-guarded comment claiming that ToNumber could not
possibly neuter the target array unfortunately turns out to
have been wishful thinking.
Bug: chromium:816961
Change-Id: Ib98f96f4cd7f33414c0b5a6037bfb881938cc15e
Reviewed-on: https://chromium-review.googlesource.com/939767
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51637}
This also adds a DCHECK that the buffer does not have guard pages in
MaterializeArrayBuffer because the code there does not know how correctly set up
a buffer with guard pages.
Bug: chromium:801849
Change-Id: Ic761fcdfbd16a2d6e87f4eb135f5d03b7aa2d71d
Reviewed-on: https://chromium-review.googlesource.com/938968
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51616}
When generating a 64bit memory operation on ia32, we need to emit two
operations, one at {offset+4}, one at {offset}. The computation
{offset+4} can overflow, which is ok because
1) it won't be used for code generation later, and
2) the generated code will not be reached because the memory access is
always out of bounds anyway.
R=ahaas@chromium.org
Bug: v8:7499, v8:6600
Change-Id: Ia4660688c3291700c48efc201d15fc370b4dd854
Reviewed-on: https://chromium-review.googlesource.com/939389
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51604}
The number of arguments passed on the stack might exceed the regular
object size limits. Hence we need to emit write barriers when copying
the arguments from the stack into the allocated array.
Bug: chromium:813450
Change-Id: I829c5c32b1a7b5f4ddb01cc6ea92f85ab47126aa
Reviewed-on: https://chromium-review.googlesource.com/939174
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51603}
Previously, Strings without an iterator would go to the runtime path
and fail on because it expected a JSReceiver type. This was in-line
with what the elements accessor expected. We can actually handle all
object types in the final slow path (using LookupIterator) so it is no
problem to change the accept types.
Bug: chromium:816289
Change-Id: Iebb8de0bb7551aee3894c8a23836d079c93726a7
Reviewed-on: https://chromium-review.googlesource.com/937461
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51574}
I loosened the DCHECKs here but I think they are still fundamentally
safe: `length` must be <= the actual length of the source (so that
there are actually enough elements to copy), and `length` must also be
<= the destination length, minus the offset (so there is enough space
to copy the elements into).
Bug: chromium:816317
Change-Id: Ice00ac60f4884363f6065ffee71f6ab1d1b32dbc
Reviewed-on: https://chromium-review.googlesource.com/937209
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51566}
IterableToListCanBeElided checked that the input was always a HeapObject
but this is not true when an iterator symbol is defined on the Number
prototype, meaning Smi and HeapNumber can also be passed in.
Added a regression test for the crash and some correctness tests for
smi and double input to TA.from.
Also factored out the tests in typedarray-from.js that modify global
state e.g. protector cells, so that one iteration of the top level
loop does not interfere with the next.
Bug: chromium:814643
Change-Id: I364d11f011faf8370446f905a35a945d47e4477f
Reviewed-on: https://chromium-review.googlesource.com/930962
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51461}
The result of an f64 binop was marked as f32 on Liftoffs value stack.
This lead to errors and is fixed in this CL.
I plan to clean up all binop implementions in a follow-up CL.
R=titzer@chromium.org
Bug: chromium:812005, v8:6600
Change-Id: I5bcd5c2e7d2b6170ef60f5e83cf2876b3475c38a
Reviewed-on: https://chromium-review.googlesource.com/924025
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51375}
This is a reland of af677f29b1, fixing
an issue with negative indices.
Original change's description:
> [ic] EmitElementStore: don't miss when hitting new space limit.
>
> CSA::EmitElementStore used to bail out (IC miss) via
> CSA::CheckForCapacityGrow when the capacity hits the new space
> limit, causing the store IC to go megamorphic in my example (see
> referenced bug). With this CL, we do what TF'ed code does already:
> call into Runtime::kGrowArrayElements (in this situation), thus
> staying monomorphic.
>
> Here's a contrived test case:
>
> ////////////////////////
> let x = [];
>
> function bar() {
> for (let i = 0; i < 50000; ++i) x[i] = i;
> }
>
> function foo() {
> for (let i = x.length; i < 100e6; ++i) x[i] = i;
> }
>
> bar();
> foo();
> ////////////////////////
>
> This took about 4s on my machine, now it takes 3s.
>
> Bug: v8:7447
> Change-Id: I7f268fc55835f363d250613ce0357444a663051c
> Reviewed-on: https://chromium-review.googlesource.com/918723
> Commit-Queue: Georg Neis <neis@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#51297}
Bug: v8:7447, chromium:812451
Change-Id: I345b5e5b2437c4f50e42bbd87947630f24cd95eb
Reviewed-on: https://chromium-review.googlesource.com/921201
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51311}
instance_class_name takes up space unnecessarily, and %_ClassOf and
class_name implement [[Class]] which isn't part of ES2015+ anymore.
Bug:
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I3a73f732ad83a616817fde9992f4e4d584638fa8
Reviewed-on: https://chromium-review.googlesource.com/776683
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51309}
According to the spec, if an imported function gets exported, the
exported function has to be identical to to imported function.
With this CL we initialize the list of potential js_wrappers_ with all
wasm function we imported. Therefore no new wrappers are generated for
these functions.
R=clemensh@chromium.org
Bug: v8:7364
Change-Id: Ibcd47d8fcc4c2fb5740d57ea547fbd01c2a4e80a
Reviewed-on: https://chromium-review.googlesource.com/901626
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51244}
This reverts commit 14108f4c2e.
Reason for revert: Not the culprit for Canary microtask crashes
Original change's description:
> [builtins] Mega-revert to address the Dev blocker in crbug.com/808911.
>
> - Revert "[builtins] Save one word in contexts for Promise.all."
> This reverts commit 7632da067b.
> - Revert "[builtins] Also use the Promise#then protector for Promise#finally()."
> This reverts commit d4f072ced3.
> - Revert "[builtins] Don't mess with entered context for MicrotaskCallbacks."
> This reverts commit 6703dacdd6.
> - Revert "[debugger] Properly deal with settled promises in catch prediction."
> This reverts commit 40dd065823.
> - Revert "[builtins] Widen the fast-path for Promise builtins."
> This reverts commit db0556b7e8.
> - Revert "[builtins] Unify PerformPromiseThen and optimize it with TurboFan."
> This reverts commit a582199c5e.
> - Revert "[builtins] Remove obsolete PromiseBuiltinsAssembler::AppendPromiseCallback."
> This reverts commit 6bf8885290.
> - Revert "[builtins] Turn NewPromiseCapability into a proper builtin."
> This reverts commit 313b490ddd.
> - Revert "[builtins] Inline InternalPromiseThen into it's only caller"
> This reverts commit f7bd6a2fd6.
> - Revert "[builtins] Implement Promise#catch by really calling into Promise#then."
> This reverts commit b23b098fa0.
> - Revert "[promise] Remove incorrect fast path"
> This reverts commit 0f6eafe855.
> - Revert "[builtins] Squeeze JSPromise::result and JSPromise::reactions into a single field."
> This reverts commit 8a677a2831.
> - Revert "[builtins] Refactor promises to reduce GC overhead."
> This reverts commit 8e7737cb58.
>
> Tbr: hpayer@chromium.org
> Bug: chromium:800651, chromium:808911, v8:5691, v8:7253
> Change-Id: I8c8ea5ed32ed62f6cd8b0d027a3707ddd891e5f1
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Reviewed-on: https://chromium-review.googlesource.com/906991
> Commit-Queue: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Adam Klein <adamk@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#51158}
Change-Id: I09d958cbebd635a325809072a290f2f53df8c5d4
Tbr: adamk@chromium.org,yangguo@chromium.org,bmeurer@chromium.org
Bug: chromium:800651, chromium:808911, v8:5691, v8:7253
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/908988
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51181}
Because of missing parentheses, the computation of the "half index" was
wrong, and always produced 0 or 1.
Also, for non-pairs, we were still passing kHighWord for the
RegPairHalf.
R=ahaas@chromium.org
Bug: v8:7422, v8:6600
Change-Id: If056aa8005d4b44e667b7d76b9be49ec0191d0eb
Reviewed-on: https://chromium-review.googlesource.com/908554
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51175}
- Revert "[builtins] Save one word in contexts for Promise.all."
This reverts commit 7632da067b.
- Revert "[builtins] Also use the Promise#then protector for Promise#finally()."
This reverts commit d4f072ced3.
- Revert "[builtins] Don't mess with entered context for MicrotaskCallbacks."
This reverts commit 6703dacdd6.
- Revert "[debugger] Properly deal with settled promises in catch prediction."
This reverts commit 40dd065823.
- Revert "[builtins] Widen the fast-path for Promise builtins."
This reverts commit db0556b7e8.
- Revert "[builtins] Unify PerformPromiseThen and optimize it with TurboFan."
This reverts commit a582199c5e.
- Revert "[builtins] Remove obsolete PromiseBuiltinsAssembler::AppendPromiseCallback."
This reverts commit 6bf8885290.
- Revert "[builtins] Turn NewPromiseCapability into a proper builtin."
This reverts commit 313b490ddd.
- Revert "[builtins] Inline InternalPromiseThen into it's only caller"
This reverts commit f7bd6a2fd6.
- Revert "[builtins] Implement Promise#catch by really calling into Promise#then."
This reverts commit b23b098fa0.
- Revert "[promise] Remove incorrect fast path"
This reverts commit 0f6eafe855.
- Revert "[builtins] Squeeze JSPromise::result and JSPromise::reactions into a single field."
This reverts commit 8a677a2831.
- Revert "[builtins] Refactor promises to reduce GC overhead."
This reverts commit 8e7737cb58.
Tbr: hpayer@chromium.org
Bug: chromium:800651, chromium:808911, v8:5691, v8:7253
Change-Id: I8c8ea5ed32ed62f6cd8b0d027a3707ddd891e5f1
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/906991
Commit-Queue: Yang Guo <yangguo@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51158}
This patch attempts to reduce the special handling of destructuring
assignments in arrow function parameters by "adopting" them from
wherever they were initially parsed into the arrow function's
FunctionState/Scope. This avoids incorrectly re-setting the
Scope of such assignments multiple times for arrow functions
that are nested inside other arrow params themselves.
It also generally seems better, in that we now only rewrite
destructuring assignments for a single function at a time.
Bug: chromium:807096
Change-Id: I6bef5613f99e3e8c130fc0aa2ee5d6fcf2efd34b
Reviewed-on: https://chromium-review.googlesource.com/900168
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51155}
Previously we would directly take the result from a fulfilled native
promise bypassing the microtask queue. This is observably different
from the spec.
Note: Our variant of the bluebird benchmark is heavily favored towards
fulfilled native promises because we don't use setTimeout (unlike the
original benchmark). I suspect this pattern doesn't appear often in
the wild so it's fine to take this hit for now.
PSA for Perf sheriffs: this is going to tank some benchmarks.
Bug: chromium:800651, v8:5691, v8:6007
Change-Id: Ic273bf2195529424b0d87359d28d5267060d5252
Reviewed-on: https://chromium-review.googlesource.com/895416
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51010}
Async generators didn't correctly handle the situation where one calls
.return on a suspended-at-start async generator and passes a
promise-like object whose awaiting causes a new request to the
generator.
Bug: chromium:805729
Change-Id: I4da13ab5bd97f8c2a2c5373242a2d5e2ab0f7f10
Reviewed-on: https://chromium-review.googlesource.com/891231
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50974}
Wide suspends have a "wide" (or "extra-wide") bytecode at their offset,
rather than the suspend itself, so they were failing the return check.
Bug: chromium:805765
Change-Id: Iabfc2a2167d09eda2f6885d9100287aadcd8fee9
Reviewed-on: https://chromium-review.googlesource.com/887082
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50923}
Do not overwrite handle values in AddNamedProperty which could cause
invalid handles in combination with CanonicalHandleScope.
Bug: chromium:802333
Change-Id: I373ab60579901bba65336ae3814e466e07392e22
Reviewed-on: https://chromium-review.googlesource.com/873032
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50890}
With the new builtin optimization guard we can just speculatively assume
that the index passed to String#charAt and String#charCodeAt (in
optimized
code) is going to be within the valid range for the receiver. This is
what Crankshaft used to do, and it avoids Smi checks on the result for
String#charCodeAt, since it can no longer return NaN.
This gives rise to further optimizations of these builtins (i.e. to
completely avoid the tagging of char codes), and by itself already
improves the regression test originally reported from 650ms to
610ms.
Bug: v8:7127, v8:7326
Change-Id: I6c160540a1e002a37e44fa7f920e5e8f8c2c4210
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/873382
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50888}
This fixes %StringIteratorPrototype%.next to not mixup
UTF16 and UTF32, and consistently use UTF32 for now.
Bug: chromium:805855
Change-Id: If58e2fe0d9bebd894e12abf8af82881c74388294
Reviewed-on: https://chromium-review.googlesource.com/888741
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50886}
This is a reland of 181ac2b0dc that fixes
the issue with load elimination.
Original change's description:
> [ic] Improve performance of KeyedStoreIC on literal-based arrays.
>
> In mode STORE_AND_GROW_NO_TRANSITION, the handler for elements stores
> used to bail out when seeing a COW array, even if the store that
> installed the handler had been operating on the very same array.
>
> This CL adds support for COW arrays to the mode (and renames it to
> STORE_AND_GROW_NO_TRANSITION_HANDLE_COW).
>
> Bug: v8:7334
> Change-Id: I6a15e8c1ff8d4ad4d5b8fc447745dce5d146c67c
> Reviewed-on: https://chromium-review.googlesource.com/876014
> Commit-Queue: Georg Neis <neis@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50840}
TBR=bmeurer@chromium.org
Bug: v8:7334, chromium:805768
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I3d9c1b08583e08d68a1d30242a25e4a2190c8c55
Reviewed-on: https://chromium-review.googlesource.com/886261
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50885}
- Introduce new helper IsFastJSArrayWithNoCustomIteration.
- Consolidates all entry array checks...
- Is a fast array (defers to BranchIfFastJSArray)
- No possibility that the Array's iteration protocol has been tampered with
- Introduce new BoolT constant helpers Int32TrueConstant and Int32FalseConstant.
Bug: chromium:804176, chromium:804188
Change-Id: I6b08396484682dc680b431ea564a7a28eeab8108
Reviewed-on: https://chromium-review.googlesource.com/883065
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50867}
When moving arguments for calls into the right registers and stack
slots, we were sometimes overwriting stack slots which would still be
used later to load arguments from. This is because we popped the (wasm)
value stack before executing the register moves, hence the stack
transfer would think the values are not being used any more and reuse
the stack slots.
With this CL, we only pop the arguments from the stack after executing
the stack transfer.
R=ahaas@chromium.org
Bug: v8:7366, v8:6600
Change-Id: I3aa5126c82634fd281959075e91e73465c39abaa
Reviewed-on: https://chromium-review.googlesource.com/883802
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50853}
Add effect input and output to String.p.char[Code]At/codePointAt.
This is necessary to fix an hard to reproduce bug, a repro for
which is included. However, the only way to get the repro
included in this CL to fail is to run it with the patch of
873382:
[turbofan] Speculate on bounds checks for String#char[Code]At
but WITHOUT this patch. This fixes a scheduling problem triggered
by 873382 that caused a bounds check to get scheduled after the
associated access.
Bug: v8:7326
Change-Id: I4b97c1726caac92ff8f74c23df2788f0ecfb1304
Reviewed-on: https://chromium-review.googlesource.com/881781
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50832}
Before we can set the length of the created array in CSA, first check
that it's possible and will do what we want. I.e. check
a) that the length is writable
b) the backing store is not copy-on-write and
c) the old length is not greater than the new length (as otherwise later
insertion past the end could restore values from the original
constructor).
If not then fall back on Runtime::kSetProperty.
Bug: chromium:804177
Change-Id: Id0e452f9d160704bbd71e87a075ba4e3983729a7
Reviewed-on: https://chromium-review.googlesource.com/880922
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50818}
When finding the initial element in A.p.reduce[Right], we did
exclude holes, but did not reflect this is the type, which still
included the hole. This CL inserts a TypeGuard to ensure that
Turbofan knows the initial element is never the hole.
Bug: chromium:804837
Change-Id: Ia118ddafb8e16dd5c02559fa23216c9b139dd59a
Reviewed-on: https://chromium-review.googlesource.com/880967
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50814}
When spilling a value to the stack, make sure to fill it as the same
type later. Otherwise, we might load garbage from the stack and violate
the assumption that the upper 32 bits of a 64 bit register are zero if
it currently holds a 32 bit value.
R=titzer@chromium.org
Bug: v8:7353, v8:6600
Change-Id: I7f2b1b31b7f3c13aa152c682cb59400fb5a3ebf0
Reviewed-on: https://chromium-review.googlesource.com/880682
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50797}
This removes the field in question to make it simpler to serialize and
deserialize modules without having to worry about the state of lazy
compilation. It is always possible to clone a non-anonymous builtin,
even without having this module-wide field.
R=clemensh@chromium.org
TEST=mjsunit/regress/wasm/regress-803427
BUG=chromium:803427
Change-Id: I72041e314eb6ee92859d45f1db0ed8500003edc4
Reviewed-on: https://chromium-review.googlesource.com/878581
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50771}
A check will fail if the context passed in is not a native context.
Change the code to get the native context from the passed context.
Bug: chromium:804288
Change-Id: Iad314a3dd170355cf524b9230a692a6329564f8a
Reviewed-on: https://chromium-review.googlesource.com/878324
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50761}
Tag RelocInfo which belongs to native wasm code, and fix printing to
not try to access the Code object for CODE_TARGET, but rather just
print "(wasm trampoline)".
Bug: chromium:801785
R=mstarzinger@chromium.org
Change-Id: I84a37f0c48ed7397cccf677b4d0f0352e5aceb9d
Reviewed-on: https://chromium-review.googlesource.com/875271
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50758}
This fixes a corner-case with lazy compilation in WebAssembly where
native-heap code did not expect to see WASM-to-JS wrappers in tables.
R=clemensh@chromium.org
TEST=mjsunit/regress/wasm/regress-803788
BUG=chromium:803788
Change-Id: Ie44b5c9efe2b171e1915295bb95d6cb61dfab3dc
Reviewed-on: https://chromium-review.googlesource.com/878262
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50755}
Array.prototype.reduce[Right] used a lazy deoptimization frame
state for an eager deopt point.
Bug: v8:7336, chromium:804096
Change-Id: I720f9e049bd6b396e025fa59192fdbc6b4f18647
Reviewed-on: https://chromium-review.googlesource.com/878120
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50752}
When the array created would exceed the maximum size for a regular heap
object, instead create it using Runtime::kNewArray directly rather than
via AllocateJSArray.
Bug: chromium:803750
Change-Id: I78cd82edf5a813a2ed69272361e0ca07f864c5ba
Reviewed-on: https://chromium-review.googlesource.com/876011
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50726}
This is needed to easily port the constructor dispatcher to CSA.
Bug: v8:7102
Change-Id: I9672416495940ca12088a2980a9ecc61364aef9d
Reviewed-on: https://chromium-review.googlesource.com/785630
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50671}
The method {SpillAllRegisters} should really just spill registers, and
not also constants. Also, since more code is inlined into that method
now, we can optimize it to update register use counters only once in
the end, since no used register should be left after executing this
method.
R=titzer@chromium.org
Bug: v8:6600, chromium:802244
Change-Id: I737a1a87f8e912151062224952c4f5dffd43f802
Reviewed-on: https://chromium-review.googlesource.com/868022
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50644}
They were in the wrong order in PreParser, which caused problem for "function
arguments() { ... }".
BUG=chromium:801772
Change-Id: Ia04c8c8c0a5d641fd1db0746dc3312c83ebcaf24
Reviewed-on: https://chromium-review.googlesource.com/865900
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50640}
This fixes a corner-case in the {NativeModuleSerializer} with modules
that do not contain any functions in the code table.
R=ahaas@chromium.org
TEST=mjsunit/regress/wasm/regress-801850
BUG=chromium:801850
Change-Id: I30cc3a26f30d8653fba2d7b99715830d12300ac2
Reviewed-on: https://chromium-review.googlesource.com/866773
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50581}
For JSCreate nodes with constant inputs we cannot simply assume that the
new.target input is a JSFunction, since it can essentially be any
JSReceiver that is a constructor, i.e. it can also be a JSBoundFunction.
Bug: chromium:801627
Change-Id: Ia37bf9c0a751e4665e1167a3771fbe166473c979
Reviewed-on: https://chromium-review.googlesource.com/866493
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50563}
Flag getters (e.g. RegExp.p.get global) are defined on the prototype and
thus we need to use the more general BranchIfFastRegExp here instead of
IsFastRegExpNoPrototype.
Bug: chromium:800538
Change-Id: Ib6bc8a4fd3bf2f7dd31538c8dbb61814106c184b
Reviewed-on: https://chromium-review.googlesource.com/859767
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50538}
This fixes a spec bug in which the order of calls to 1) the flag getter
and 2) ToUint32(limit) was incorrect if ToUint32 pushes the regexp
instance onto the slow path. We are now more restrictive and completely
avoid ToUint32 on the fast path.
Bug: chromium:801171
Change-Id: I21d15fe566754d2bc05853f895636bb882fbf599
Reviewed-on: https://chromium-review.googlesource.com/863644
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50533}
Band-aid fix for infinite recursion in RegExp TFJ builtins.
TFJ builtins don't contain stack checks in general, so any deep
recursion involving only TFJ builtins can end up overflowing the stack
and segfaulting on the red area.
RegExp builtins in particular can only build such recursions using
RegExp.p.exec, and (as far as I can tell) only by modifying the instance
or prototype, thus hitting the slow path in all builtins.
This CL adds a stack check to RegExpExec, which is the choke point for
calling exec on slow-mode RegExps.
Bug: v8:7239, chromium:797481
Regression test
Change-Id: I78dbb5f868a775d9697606d513623f912639d7db
Reviewed-on: https://chromium-review.googlesource.com/856777
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50511}
Ensure that for setcc, we only use a byte register as destination
register.
R=titzer@chromium.org
Bug: v8:6600, chromium:800756
Change-Id: Ie33f3faf602e7eda845205ba0ed2d9966460fd54
Reviewed-on: https://chromium-review.googlesource.com/860640
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50508}
Update tests to work with new behavior.
Thanks Yang Guo for fixing the GC problem in
ad126d46bbR=adamk@chromium.org, machenbach@chromium.org
Q_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
Bug: v8:4958
Change-Id: Ia7d9417f80087fb6df4ef877d0b4357875ee6c30
Reviewed-on: https://chromium-review.googlesource.com/834458
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Josh Wolfe <jwolfe@igalia.com>
Cr-Commit-Position: refs/heads/master@{#50486}
Drive-by-cleanup:
- Add InternalElementsAccessor to expose protected instance methods
to ElementsAccessor subclasses.
- Make some more ElementsAccessor methods protected that take the
raw entry as parameter.
Bug: chromium:798644
Change-Id: Iffd00f1953461e8dd22c123e62298410fb6e049c
Reviewed-on: https://chromium-review.googlesource.com/856816
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50480}
Loop headers contain a stack check in wasm, hence an exception can be
thrown at the position of the loop instruction. This means that for
asm.js, we need to store a source position for each loop instruction.
R=mstarzinger@chromium.org
Bug: chromium:799690
Change-Id: I129abef11461992e2f10af8e6afc28ce1cf83341
Reviewed-on: https://chromium-review.googlesource.com/856338
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50443}
In d8 a script is executed in a RealmScope. However, all micro task
which are created by the script are not executed within the RealmScope
at the moment. With this CL I move the execution of the micro task into
the RealmScope.
I thought about creating a new RealmScope for the micro tasks, but
(1) It did not fix the crashing repro;
(2) It seems wrong that the micro tasks are executed in a different
realm than the script;
Therefore I just moved the execution of the micro tasks into the
RealmScope of the script.
Thereby I moved the execution tasks also into the Context::Scope of the
script. The problem is that the Context::Scope surrounds the RealmScope,
and when I to open the RealmScope before the Context::Scope, not even
the execution of the script works anymore.
R=yangguo@chromium.org
Bug: chromium:797846
Change-Id: If152af282beec8f0b0564dcc9682fee8588e142c
Reviewed-on: https://chromium-review.googlesource.com/856497
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50442}
The checked node and used node were mismatched. It checked if
"var_unique" is a string, but it used "key" which may not be a string.
Bug: v8:4911, v8:7161, chromium:800077
Change-Id: Ia2aee8b77ac33500430365a4800bf9cca40a28fc
Reviewed-on: https://chromium-review.googlesource.com/855138
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50435}
There were two separate bugs here. First, a signed/unsigned mismatch
where we took the result of PositiveNumberToUint32 and treated it as a
signed int. Second, AdvanceStringIndex did not handle large input
values correctly.
Both are fixed by using uint64_t consistently.
Bug: chromium:799813, v8:7258
Change-Id: If2819f87986d0ca732bc24df290f6dc7614083e8
Reviewed-on: https://chromium-review.googlesource.com/854272
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50432}
The initial fast array may change, invalidating assumptions.
Bug: chromium:798026
Change-Id: Iddcc40867221a2a58aef33b64e7399e0f2784e89
Reviewed-on: https://chromium-review.googlesource.com/850356
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50363}
Fixes a regression causing a seg fault instead of the
expected stack overflow.
Bug: chromium:796427, v8:6005
Change-Id: Ifc752a4009a25f447f5e87745dcc1bb83722c34e
Reviewed-on: https://chromium-review.googlesource.com/838854
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50265}
Move the object and array literal flag and depth initialization to when
they are visited by the bytecode generator. This avoids issues with
doing this initialization before we know whether the (syntactic) literal
is actually a literal value or a destructuring assignment.
Bug: chromium:795922
Bug: v8:7178
Change-Id: I022178ab4bc9e71f80560f3b78a759d95d4d0584
Reviewed-on: https://chromium-review.googlesource.com/833882
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50204}
Update tests to work with new behavior.
This feature is shipping in Firefox 54, so compatibility risk is low.
R=littledan@chromium.org, adamk@chromium.org, caitp@igalia.com
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
Bug: v8:4958
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Ib16d19468cf935f961d7bcd856ebbeb5692d3e61
Reviewed-on: https://chromium-review.googlesource.com/546941
Commit-Queue: Josh Wolfe <jwolfe@igalia.com>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50178}
Instruction selector computes the range of case statement labels
to choose between a table or lookup based switch. We need to special
case this when there are no case statements.
Bug: chromium:794825
Change-Id: I46ef57d17f5e2b99a3570f7f3c4ff06e75d78fab
Reviewed-on: https://chromium-review.googlesource.com/830013
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50153}
The irregexp compiler expects RegExpCharacterClass instances to
contain at least one range. This preserves that invariant when parsing
the negated \P{Any} unicode property.
Bug: chromium:793588
Change-Id: If71fdce014a7e64d8af559084ee88108303d694b
Reviewed-on: https://chromium-review.googlesource.com/827010
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Erik Corry <erikcorry@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50146}
The unicode property escape syntax restricts unicode property names and
unicode property values to consist only of characters taken from the
[a-zA-Z0-9_] character class. See the spec at:
https://tc39.github.io/proposal-regexp-unicode-property-escapes/
In most cases, we do not actually need to validate that this is the
case, since subsequent property lookup in ICU will fail (and throw a
SyntaxError) if the given property does not exist.
However, there one special case. The ICU lookup takes the property name
as a null-terminated string, so it will accept carefully malformed
property names (e.g. '\p{Number\0[}'). This can end up confusing the
regexp parser.
With this CL, we explicitly restrict potential property names / values
to the character set as specified.
Bug: v8:4743, chromium:793793
Change-Id: Ic97deea8602571ec6793b79c4bb858e1c7597405
Reviewed-on: https://chromium-review.googlesource.com/824272
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50130}
In a generator containing loops, there are always certain control flow
paths that are impossible, due to the way we represent generators at the
bytecode level. Unfortunately, the graph builder can't tell that these
paths are impossible. In combination with dead code, it can then happen
that we build a subgraph (for unreachable code) whose incoming context
is the undefined oddball. JSContextSpecialization did not expect that.
Bug: chromium:794822
Change-Id: I259be5ae6c5f5adc8fca19c64bf71285ee922b7a
Reviewed-on: https://chromium-review.googlesource.com/828954
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50129}
This makes sure the builtin lowering of Object.create doesn't invalidate
any previously taken dependencies. Aborting compilation after such cases
would lead to repeating optimization attempts without learning, hence we
disallow such situations.
R=verwaest@chromium.org
BUG=chromium:794394,chromium:786723
Change-Id: I6b6928cab19692bbbe3cd241ade862a2306eb0c7
Reviewed-on: https://chromium-review.googlesource.com/827066
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50128}
If an initializer is a NaryOperation, its position ends up as a start position
of a Scope, and a DCHECK used to fire.
Interestingly, this was not caught by our existing tests.
BUG=chromium:791256
Change-Id: Id47f850c7ad17ca580352f9bd56c9567b485c3b8
Reviewed-on: https://chromium-review.googlesource.com/822093
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50051}
This is a reland of c3bd741efd
Original change's description:
> Fix "this" value in lazily-parsed module functions.
>
> When preparsing top-level functions in a module, we didn't track
> unresolved variables. Consequently, "this" ended up referencing
> the global "this", which has the wrong value (in a module "this"
> is supposed to be the undefined value).
>
> This patch fixes that. This also lets us stop forcing context
> allocation of all variables in module scopes, which the patch
> takes care of as well.
>
> Bug: chromium:791334
> Change-Id: Ifac1f1adc033f3facfb3d29dd4bca32ee27bffcf
> Reviewed-on: https://chromium-review.googlesource.com/808938
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50025}
TBR=adamk@chromium.orgTBR=kozyatinskiy@chromium.org
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Bug: chromium:791334
Change-Id: I57acc7b84a345565b36cbb55924fa2ff9b449eec
Reviewed-on: https://chromium-review.googlesource.com/822341
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50045}
This reverts commit c3bd741efd.
Reason for revert: Breaks layout tests:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/20384
Original change's description:
> Fix "this" value in lazily-parsed module functions.
>
> When preparsing top-level functions in a module, we didn't track
> unresolved variables. Consequently, "this" ended up referencing
> the global "this", which has the wrong value (in a module "this"
> is supposed to be the undefined value).
>
> This patch fixes that. This also lets us stop forcing context
> allocation of all variables in module scopes, which the patch
> takes care of as well.
>
> Bug: chromium:791334
> Change-Id: Ifac1f1adc033f3facfb3d29dd4bca32ee27bffcf
> Reviewed-on: https://chromium-review.googlesource.com/808938
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50025}
TBR=adamk@chromium.org,marja@chromium.org,neis@chromium.org,kozyatinskiy@chromium.org
Change-Id: I81f69334ed2ce104c00e6205d50001e4bdf07d15
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:791334
Reviewed-on: https://chromium-review.googlesource.com/822258
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50036}
When preparsing top-level functions in a module, we didn't track
unresolved variables. Consequently, "this" ended up referencing
the global "this", which has the wrong value (in a module "this"
is supposed to be the undefined value).
This patch fixes that. This also lets us stop forcing context
allocation of all variables in module scopes, which the patch
takes care of as well.
Bug: chromium:791334
Change-Id: Ifac1f1adc033f3facfb3d29dd4bca32ee27bffcf
Reviewed-on: https://chromium-review.googlesource.com/808938
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50025}
Moving a register to itself is not only unnecessary overhead, it also
breaks invariants in the StackTransferRecipe.
R=ahaas@chromium.org
Bug: v8:6600, chromium:793551
Change-Id: I659fd66b4f2d4564c437ed9fb048322af4299d97
Reviewed-on: https://chromium-review.googlesource.com/819231
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49992}
When enabling any coverage mode (other than best-effort), we trigger
deoptimization of all functions on the heap.
Prior to the recent removal of the weak list of optimized functions [0],
we'd unlink optimized code from all relevant JSFunctions during the call
to DeoptimizeAll.
After the weak-list-removal, this was no longer the case, hence this [1]
change which attempts to reset the code object from the
SharedFunctionInfo for all found JSFunction objects.
But this can create a situation in which JSFunctions are set up
incorrectly s.t. they have unoptimized code but no feedback vector.
This CL fixes that by leaving JSFunction objects untouched and relying
on self-healing mechanisms (CompileLazyDeoptimizedCode) to fix up
JSFunction::code.
[0] https://crrev.com/f0acede9bb05155c25ee87e81b4b587e8a76f690
[1] https://crrev.com/c/647596/5/src/debug/debug-coverage.cc
Bug: chromium:786784, chromium:791940, v8:6637
Change-Id: I13191f4c8800a0d72894b959105189dc09ca693e
Reviewed-on: https://chromium-review.googlesource.com/813615
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49932}
Ensure that the type is always stored correctly.
R=titzer@chromium.org
Bug: v8:6600, chromium:791810
Change-Id: Id3a3c20b14f8730b9550c548dec49ac47121e691
Reviewed-on: https://chromium-review.googlesource.com/811188
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49924}
This unblocks the checks in the SimplifiedLowering that whenever we
store something as TaggedSigned, the input type should at least be
Type::SignedSmall.
Bug: chromium:791245
Change-Id: Ice6e55c2c6584c0ff60c1e033ba755c8863af32a
Reviewed-on: https://chromium-review.googlesource.com/808104
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49856}
We'd sometimes forget that the input was not originally a numeric.
Bug: v8:7135
Change-Id: I8bc690cc0c2dfac8a2a218ca56352b6a569825dc
Reviewed-on: https://chromium-review.googlesource.com/793039
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49667}
1) Make sure we don't enable prototype setup mode for parent class and its prototype
objects.
2) Make sure we create builtins and their prototypes with completed setup mode.
3) Drive-by-fix: setup typed array classes in bootstrapper.cc instead of typedarray.js,
and drop %FunctionSetPrototype().
Bug: v8:7115, v8:5902
Change-Id: I58ac091d85647abc3307bd47baf48e378e3695c5
Reviewed-on: https://chromium-review.googlesource.com/790992
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49655}
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}
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}
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 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 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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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 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}
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}
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}
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}
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}
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}
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}
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}
Support inlining of Array.prototype.filter in TurboFan.
Bug: v8:1956
Change-Id: If50e230d14461063d378c0591dc27dea43371afa
Reviewed-on: https://chromium-review.googlesource.com/733089
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48846}
If the buffer associated with WebAssembly.Memory is used as memory
for asm.js modules, throw a range error on Memory.Grow.
Bug: chromium:776677
Change-Id: Iebcd7797fa7724002dd8073d1dbaeb98f080d316
Reviewed-on: https://chromium-review.googlesource.com/731844
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48837}
Fixes the implementation of step 9 in the Proxy's internal [[Get]]
method:
Let targetDesc be ? target.[[GetOwnProperty]](P)
If P is an accessor, this should not result in a call to the getter.
Likewise in [[Set]] and [[Has]].
https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-get-p-receiver
Bug: chromium:776338
Change-Id: I2652ffab2b3e4c38de00a82b8419192fdc768951
Reviewed-on: https://chromium-review.googlesource.com/732897
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48825}
This reverts commit 14165a47d4.
Reason for revert: Fix is incomplete, will reland soon.
Original change's description:
> [proxy] Fix invalid call to getter in [[Get/Set]]
>
> Fixes the implementation of step 9 in the Proxy's internal [[Get]]
> method:
>
> Let targetDesc be ? target.[[GetOwnProperty]](P)
>
> If P is an accessor, this should not result in a call to the getter.
> Likewise in [[Set]].
>
> https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-get-p-receiver
>
> Bug: chromium:776338
> Change-Id: Ic06b7eeac6a1ef9606ddda6fa9d6d58b709702fb
> Reviewed-on: https://chromium-review.googlesource.com/731123
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48813}
TBR=neis@chromium.org,jgruber@chromium.org
Change-Id: I92a11791b3c6a73ada1f72fe4193c25e7a054746
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:776338
Reviewed-on: https://chromium-review.googlesource.com/732877
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48815}
Fixes the implementation of step 9 in the Proxy's internal [[Get]]
method:
Let targetDesc be ? target.[[GetOwnProperty]](P)
If P is an accessor, this should not result in a call to the getter.
Likewise in [[Set]].
https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-get-p-receiver
Bug: chromium:776338
Change-Id: Ic06b7eeac6a1ef9606ddda6fa9d6d58b709702fb
Reviewed-on: https://chromium-review.googlesource.com/731123
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48813}
[wasm] Fix signature canonicalization for error case.
The decoder should not attempt to insert null signatures into the SignatureMap.
R=ahaas@chromium.org
Bug: chromium:775366
Change-Id: I0fbc0547dbf00fd25d37271a03b6756481a4c6a1
Reviewed-on: https://chromium-review.googlesource.com/730752
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48793}
In the special case of KeyedLoadIC, where the key that is passed in is a
Name that is always the same we only checked for identity in both the
stub and the TurboFan case, which works fine for symbols and internalized
strings, but doesn't really work with non-internalized strings, where
the identity check will fail, the runtime will internalize the string,
and the IC will then see the original internalized string again and not
progress in the feedback lattice. This leads to tricky deoptimization
loops in TurboFan and constantly missing ICs.
This adds fixes the stub to always try to internalize strings first
when the identity check fails and then doing the check again. If the
name is not found in the string table we miss, since in that case the
string cannot match the previously recorded feedback name (which is
always a unique name).
In TurboFan we represent this checks with new CheckEqualsSymbol and
CheckEqualsInternalizedString operators, which validate the previously
recorded feedback, and the CheckEqualsInternalizedString operator does
the attempt to internalize the input.
Bug: v8:6936, v8:6948, v8:6969
Change-Id: I3f3b4a587c67f00f7c4b60d239eb98a9626fe04a
Reviewed-on: https://chromium-review.googlesource.com/730224
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48784}
This reverts commit 9fd029ef25.
Due to a ClusterFuzz issue.
TBR=mstarzinger@chromium.org
Bug: chromium:776511
Change-Id: I0f30e2e8de97f3c437a1756c82e645828358ad91
Reviewed-on: https://chromium-review.googlesource.com/730006
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48775}
Also ensure that CSA's CloneFixedArray and ExtractFixedArray correctly
transition COW to non-COW maps when doing a clone requiring copying.
Bug: chromium:775888
Change-Id: I31c97072761fdd2360d86f840c9fd6ab2d72973a
Reviewed-on: https://chromium-review.googlesource.com/727900
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48754}
The bug reference has been fixed, probably due to the new WasmContext
changes. We should keep a regression test for this anyway though.
Bug: v8:6931
Change-Id: Ie9d94690e764498d2153691d96414d0d26258794
Reviewed-on: https://chromium-review.googlesource.com/727022
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48712}
Support inlining of Array.prototype.filter in TurboFan.
(relanding with fix for chromium:766635, visible in the
diff between patchsets 2 and 3)
Bug: v8:1956,chromium:766635
Change-Id: Ia50be6770602513e3d91d17e2b2ca9d3b0e8b42a
Reviewed-on: https://chromium-review.googlesource.com/721119
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48697}
These tests are currently failing on TSAN bot with OOM when running
with the stress-incremental-marking flag.
Bug: v8:6924
Change-Id: I50b9a7142b2e8759f4bc327516f8c06ce1779777
Reviewed-on: https://chromium-review.googlesource.com/723427
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48693}
A while ago, CharacterRange::AddCaseEquivalents used to operate on a
single range (the `this` value) and add case equivalents for that to
`ranges`.
This was changed in a2baaaac to use `ranges` as a list of incoming
operands instead. When we now determine that the current range does not
have case equivalents, we need to `continue` instead of `return` to
avoid skipping the remaining ranges in the list.
Bug: v8:6940
Change-Id: I9face88a2ef8b9408f177e503f3399a25e688e06
Reviewed-on: https://chromium-review.googlesource.com/725430
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48682}
This makes sure that the lowering of {JSCreate} operator during create
lowering is only applied to operations where both target and new.target
are known to be constructors.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-768080
BUG=chromium:774780,chromium:768080
Change-Id: I55a582a3453bba7e14655b594b7714a3940eeaae
Reviewed-on: https://chromium-review.googlesource.com/725332
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48680}
Inner functions which called eval, and were the kind of functions
that can use `super`, were erroneously not marked as "uses_super_property",
leading to downstream crashes when the runtime tried to load the
[[HomeObject]] from them.
This patch eliminates the public Scope::uses_super_property()
API and ensures that callers always call Scope::NeedsHomeObject()
instead.
This is a minimal fix designed for easy merging; it's likely that
in the long run we should remove most mentions of "uses super property"
and replace them with "needs home object" for clarity.
Bug: v8:5516, chromium:774994
Change-Id: Id269dd33e35bd40f6b59a3d3e19330687afa64f8
Reviewed-on: https://chromium-review.googlesource.com/721879
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48619}
When skipping inner funcs is enabled, we also track variables for top level
funcs. Thus, we also declared the function name for the function scope, even
though it was the function scope for a function whose preparsing was
aborted. This lead into declaring the function name twice.
The fix is to declare the function name only in the success case.
The code was "wrong" before too, but this was never a problem, since variable
tracking and aborting preparsing were enabled for disjoint sets of
functions (aborting preparsing only for top-level, and variable tracking for
non-top-level).
BUG=v8:5516,chromium:774475
Change-Id: Ie6c321cc834cd946e8843f73916fa7dd75e9cd09
Reviewed-on: https://chromium-review.googlesource.com/720920
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48592}
This patch introduces assertPromiseFulfills and assertPromiseFulfills as
a replacement for assertPromiseResult because it’s more JavaScript-y.
BUG=v8:6921
R=ahaas@chromium.org
Also-By: ahaas@chromium.org
Change-Id: I2f865dba3992ddf3b58987bf0b376d143edb5c31
Reviewed-on: https://chromium-review.googlesource.com/718746
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48578}
This adds and explicit check for the constructability of the new.target
value in the lowering of {JSCall} nodes known to call Reflect.construct.
The {JSConstruct} operator does not perform this check and relies on the
implicit validity of new.target in all other use cases.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-768080
BUG=chromium:768080
Change-Id: I7c1921e787bae64ba83de3eb08aa00fc5523e251
Reviewed-on: https://chromium-review.googlesource.com/718100
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48543}
This propagates the existing type of a {JSAdd} node back to the newly
created {Allocate} node. There are cases where said type is {None}.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-772720
BUG=chromium:772720
Change-Id: Iab18d2108a789b51db4e405f7f335c5c0ca6f686
Reviewed-on: https://chromium-review.googlesource.com/708796
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48493}
Skipped the tests that are not suitable for deoptimization fuzzing.
regress/regress-2618 test fixed to check kMaybeDeopted flag.
Minor code style fix in mjsunit.js.
Bug: v8:6900
Change-Id: Icc02a6b99005ae08ee7cb6cf2c1e9137329d79d3
Reviewed-on: https://chromium-review.googlesource.com/708797
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48444}
This makes sure that frames representing builtin stub continuations not
only materialize all stack slots, but also spilled register values. Note
that this also applies when the stub frame is not the top-most frame.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-6907
BUG=v8:6907
Change-Id: I01a2edf5629de6aac61ceea350d1ab5f91dc2dc1
Reviewed-on: https://chromium-review.googlesource.com/707245
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48415}
This ensures the JSFunction objects materialized by the deoptimizer have
the correct instance size (depending on the given map). There are corner
cases where the instance size might vary due to in-object properties.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-772610
BUG=chromium:772610
Change-Id: I4808c7260db1adbd1cdc3871c2a946475e4934f2
Reviewed-on: https://chromium-review.googlesource.com/707109
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48383}
The escape analysis is able to perform scalar replacement on JSArrays
with in-object properties (which currently only happens for subclasses
of the Array constructor), but the Deoptimizer didn't properly
materialized and initialized the values of the in-object fields so far.
Bug: chromium:772689, v8:6399
Change-Id: I6555a46773d2a1543db069142aa05f4337566b9c
Reviewed-on: https://chromium-review.googlesource.com/706781
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48365}
The code used to rely on all such loops having a block scope around
them, but that is no longer the case for loops whose loop variables
are VAR-declared.
This patch introduces a new DeclarationDescriptor::Kind for such
variables, and sets it during parsing, allowing the variable
declaration code to note them as assigned appropriately.
Bug: chromium:768158
Change-Id: I0cd60e8c8c735681be9dbb9344a93156af09c952
Reviewed-on: https://chromium-review.googlesource.com/701624
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48320}
This reverts commit 5e76ff5a4a.
Reason for revert: tsan failures - https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/17574
Original change's description:
> Reland "[wasm] always allocate memory when guard regions are needed"
>
> This reverts commit 7cf29d8df3.
>
> Original change's description:
> > [wasm] always allocate memory when guard regions are needed
> >
> > When using trap handlers, memory references do not get any checks inserted. This
> > means there is no check for a null memory as happens when the memory size is
> > 0. Normally this would be correctly caught as an out of bounds access, since the
> > low memory addresses are not normally mapped. However, if they were mapped for
> > some reason, we would not catch the out of bounds access.
> >
> > The fix is to ensure WebAssembly instances always have a guard region even if
> > the memory is size 0.
> >
> > Bug: chromium:769637
>
> Change-Id: I09fdaea92b7ccb3a6cc9e28392171ec098538a00
> Reviewed-on: https://chromium-review.googlesource.com/695812
> Commit-Queue: Eric Holk <eholk@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48293}
TBR=gdeepti@chromium.org,mtrofin@chromium.org,mlippautz@chromium.org,eholk@chromium.org,eholk@google.com,clemensh@chromium.org
Change-Id: I52d5354126158a92602b08c48703d562ac95075b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/699599
Reviewed-by: Eric Holk <eholk@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48294}
This reverts commit 7cf29d8df3.
Original change's description:
> [wasm] always allocate memory when guard regions are needed
>
> When using trap handlers, memory references do not get any checks inserted. This
> means there is no check for a null memory as happens when the memory size is
> 0. Normally this would be correctly caught as an out of bounds access, since the
> low memory addresses are not normally mapped. However, if they were mapped for
> some reason, we would not catch the out of bounds access.
>
> The fix is to ensure WebAssembly instances always have a guard region even if
> the memory is size 0.
>
> Bug: chromium:769637
Change-Id: I09fdaea92b7ccb3a6cc9e28392171ec098538a00
Reviewed-on: https://chromium-review.googlesource.com/695812
Commit-Queue: Eric Holk <eholk@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48293}
The code in `AsmJsScanner::Next()` checks for both
end of input and parse error:
if (token_ == kEndOfInput || token_ == kParseError) {
return;
}
but until now the code in the parsing loop only checked
for `kEndOfInput`, resulting in an infinite loop on
`kParseError`.
R=bradnelson@chromium.org, mstarzinger@chromium.org
Bug: chromium:771428
Change-Id: I9170f090503590b3b9b949a0d00ab4daef85bf66
Reviewed-on: https://chromium-review.googlesource.com/699994
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48290}
This makes sure that helper methods on the {TranslatedState} class stick
to the counting scheme used by {OptimizedFrame::Summarize} within the
stack-walker. Both now treat {kJavaScriptBuiltinContinuation} as real
JavaScript frames.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-770543
BUG=chromium:770543
Change-Id: Icda65a7efb487470d39ebf648767a488ebf2e5f1
Reviewed-on: https://chromium-review.googlesource.com/695123
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48264}
This makes sure the deoptimizer properly materializes heap objects, even
when the top-most frame happens to be a stub-frame. Without this step
the {arguments_marker} would leak into user-land and most likely be
treated as an undefined value.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-769852
BUG=chromium:769852
Change-Id: I4ba17501c5d7e68d1f402b7c2cc5ccb0fb7bfb05
Reviewed-on: https://chromium-review.googlesource.com/691996
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48262}
In JS to Wasm wrappers, arguments have to be converted from JavaScript's
representation to Wasm's representation. Because of property accessors, this can
result in JavaScript or even asm.js/Wasm code being run. We were previously
setting this flag before doing the parameter conversions, and if these
conversions triggered a Wasm property getter then we would try to set the flag
twice.
With this change, we wait until after all argument conversions are done to set
the flag.
Bug: chromium:769846
R=bradnelson@chromium.org
Change-Id: Ia4b56df45619dcad69f3750bb33cacfedcaeb5b2
Reviewed-on: https://chromium-review.googlesource.com/693414
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48244}
This reverts commit 1f99c66b56.
Reason for revert: Test timeouts on Win64 Debug: https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20debug/builds/19226
Original change's description:
> [wasm] always allocate memory when guard regions are needed
>
> When using trap handlers, memory references do not get any checks inserted. This
> means there is no check for a null memory as happens when the memory size is
> 0. Normally this would be correctly caught as an out of bounds access, since the
> low memory addresses are not normally mapped. However, if they were mapped for
> some reason, we would not catch the out of bounds access.
>
> The fix is to ensure WebAssembly instances always have a guard region even if
> the memory is size 0.
>
> Bug: chromium:769637
> Change-Id: I2d0f8c107563236c3780eb7746c2f820e319c65f
> Reviewed-on: https://chromium-review.googlesource.com/693137
> Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
> Commit-Queue: Eric Holk <eholk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48240}
TBR=gdeepti@chromium.org,mtrofin@chromium.org,eholk@chromium.org
Change-Id: I4065b367c6cfffe8dd601b67cd53ad54759ae96a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:769637
Reviewed-on: https://chromium-review.googlesource.com/692918
Reviewed-by: Eric Holk <eholk@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48242}
When using trap handlers, memory references do not get any checks inserted. This
means there is no check for a null memory as happens when the memory size is
0. Normally this would be correctly caught as an out of bounds access, since the
low memory addresses are not normally mapped. However, if they were mapped for
some reason, we would not catch the out of bounds access.
The fix is to ensure WebAssembly instances always have a guard region even if
the memory is size 0.
Bug: chromium:769637
Change-Id: I2d0f8c107563236c3780eb7746c2f820e319c65f
Reviewed-on: https://chromium-review.googlesource.com/693137
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48240}
This fixes the signature of "Math.abs" from "(signed) -> signed" to
"(signed) -> unsigned" and hence fixes cases where the absolute value
would overflow the range of signed 32-bit values. This is in sync with
spec erratas (and ECMAScript semantics).
Note that this also switches the underlying implementation of the above
absolute value function to a branch-free version.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-6838-3
BUG=v8:6838
Change-Id: Ib13b7ecd336ae386cbde7c574e727bf52f841e00
Reviewed-on: https://chromium-review.googlesource.com/684181
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48169}
This fixes the signatures of "Math.ceil", "Math.floor" and "Math.sqrt"
from "(float?) -> float" to "(float?) -> floatish" which avoids using a
resulting float value without coercing the value via explicit "fround"
annotations. This ensures proper ECMAScript semantics are maintained.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-6838-2
BUG=v8:6838
Change-Id: Ib5821641265bc862184adb270e8dbf8c703fdfb0
Reviewed-on: https://chromium-review.googlesource.com/681694
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48142}
This fixes the signature of "Math.min" and "Math.max" for integer values
from "(int, int...) -> signed" to "(signed, signed..) -> signed" which
properly distinguishes signed from unsigned values now. This is in sync
with the spec errata (and ECMAScript semantics).
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-6838-1
BUG=v8:6838
Change-Id: Id72836513dd86e93472a22cf1ac2e2d382ed4f23
Reviewed-on: https://chromium-review.googlesource.com/681357
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48139}
Memory instantiate on initialize should always patch memory
references. If memory references are not patched for no initial
memory, on subsequent calls to grow_memory in wasm functions for
instances that share a module, the references will be patched
without resetting cloned compiled values to their correct initial
values.
BUG=chromium:763439
Change-Id: I666439332379b02aa344e99d61ef3dc88ab86cc8
Reviewed-on: https://chromium-review.googlesource.com/674707
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48097}
Support inlining of Array.prototype.filter in TurboFan.
Bug: v8:1956
Change-Id: Iba4d683aaa86c6104e8a1cf4d0f549a0c516576a
Reviewed-on: https://chromium-review.googlesource.com/657021
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48040}
SetForceInlineFlag is now only used in tests. Earlier, it was also used
in js builtins, because unless this flag was specified the js builtins
were not inlined. All the performance critical js builtins are moved
to turbofan builtins and SetForceInlineFlag is no longer used. We would
like to remove this flag completely to simplify inlining heuristics.
Also, this uses a bit on the SharedFuntionInfo.
Bug: v8:6682
Change-Id: I19afd27381afc212f29179f2c5477095c8174f39
Reviewed-on: https://chromium-review.googlesource.com/660739
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47997}
The wasm valiation incorrectly allowed simd locals, even without the
experimental flag turned on. This was not noted in the generated code
because simd opcodes were forbidden, but the interpreter could not
handle these locals.
R=clemensh@chromium.org
Bug: chromium:763697
Change-Id: I11d924ac21e50bce81d0504c2c7b252105a89f80
Reviewed-on: https://chromium-review.googlesource.com/660117
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47946}
The Typer put the wrong type on String#index and String#lastIndexOf
builtins, with an off by one on the upper bound.
Bug: chromium:762874
Change-Id: Ia4c29bc2e8e1c85b6a7ae0b99f8aaabf839a5932
Reviewed-on: https://chromium-review.googlesource.com/660000
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47942}
It's quite common today to use Function#apply together with typed
arrays, for example to construct a String from character codes (or code
points) within a Uint8Array or Uint16Array, i.e.
String.fromCharCode.apply(undefined, uint8array)
is seen quite often on the web. But there are other interesting cases
like
Math.max.apply(undefined, float64array)
to compute the maximum value in a Float64Array, which is definitely not
the fastest implementation, but quite convenient and readable.
Unfortunately these cases hit the super-slow-path of the Function#apply
machinery in V8 currently, because Function#apply doesn't have any
fast-path for TypedArrays.
This CL adds a proper fast-path to CreateListFromArrayLike to the
ElementsAccessor, which can be used as long as the typed array that's
passed wasn't neutered. With this fast-path in place, the performance on
the micro-benchmark mentioned in the issue improves from
stringFromCharCode: 6386 ms.
stringFromCodePoint: 8752 ms.
to
stringFromCharCode: 1932 ms.
stringFromCodePoint: 4262 ms.
which corresponds to a 2.0x-3.3x improvement.
Bug: v8:2435
Change-Id: I4d39666e53644b11d5856982b005928e26f296fe
Reviewed-on: https://chromium-review.googlesource.com/657405
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47936}
TSAN finds data races in generated JavaScript code that use
access the SharedArrayBuffer backing store racily. These are races, but
they are OK in the sense that the JavaScript memory model allows for the
potential bad behavior they could introduce (e.g. potentially tearing
reads). Relaxed atomics could be used here instead, but that could
introduce performance regressions.
This change adds TSAN annotations to the TypedArray reads/writes to
prevent TSAN from warning about them.
Bug: chromium:722871
Change-Id: I0776475f02a352b678ade7d32ed6bd4a6be98c36
Reviewed-on: https://chromium-review.googlesource.com/656509
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47929}
What happened:
- When rewriting in DoParseFunction, the relevant function scope is no longer in
the scope stack.
- The correct scope is given to the PatternRewriter.
- PatternRewriter called to Parser::BuildIteratorCloseForCompletion.
- BuildIteratorCloseForCompletion would just call NewTemporary (which creates
a new temporary in Parser's current scope) instead of using the scope passed to
it and calling NewTemporary on it.
- Normally this went unnoticed, since it doesn't matter that much where the
temporary is.
- But in the lazy arrow func case, the Parser's scope at that point was the
already-resolved outer scope, and a DCHECK detected this problem.
Kudos & thanks to verwaest@ for a debugging session :)
BUG=chromium:761831
Change-Id: I1e8474ce927be0330f4ba4efc0fc08fdcc328809
Reviewed-on: https://chromium-review.googlesource.com/650297
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47877}
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 makes sure the minimum memory size for WebAssembly modules derived
from asm.js is set to zero. It allows instatiation without allocating an
underlying memory, when such memory is unused. It also fixes a bug in
patching of embedded memory sizes for asm.js modules.
R=ahaas@chromium.org
TEST=mjsunit/regress/regress-crbug-759327
BUG=chromium:759327
Change-Id: If5a965b96a03cbb5ba15bc41fbaf359f74961f41
Reviewed-on: https://chromium-review.googlesource.com/637912
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47646}
We cannot assume that the receiver is a JSObject, nor can we assume
ToObject() completes successfully.
TBR=yangguo@chromium.org
Bug: chromium:739954
Change-Id: Id55571131ef8755e86f15cd2acb918ff0f1b7788
Reviewed-on: https://chromium-review.googlesource.com/632376
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47611}
The Uint32(limit) conversion can end up transitioning the regexp
instance to slow mode. In this case we need to bail out to runtime while
ensuring that ToUint32 is not observably called a second time. We do
this by passing the already-converted value to runtime.
This particular path was broken and we ended up passing the original
maybe_limit value to runtime instead.
TBR=yangguo@chromium.org
Bug: chromium:758763
Change-Id: If7f23b452d2e134ad9be3d4ef1d78d1c946fcef0
Reviewed-on: https://chromium-review.googlesource.com/635588
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47609}
This makes sure instantiate of asm.js modules fails gracefully on heap
buffers exceeding the uint32_t range supported by WebAssembly.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-crbug-754175
BUG=chromium:754175
Change-Id: I4a9c6791beaab6da826b5b6b5a495f97e9d3b4e9
Reviewed-on: https://chromium-review.googlesource.com/632618
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47598}
BytecodeGenerator previously assumed that any UNALLOCATED variable
must be a global object property, but that's incorrect for global
lexical variables declared in a different script.
This patch fixes the behavior by always falling back to the runtime
to deal with deleting UNALLOCATED variables. This is sub-optimal,
but should be correct, and it's unclear if speed is important for
this case.
Bug: v8:6733
Change-Id: I83c2a0b6e30e5e5f4c79bfe14ebf196529816c71
Reviewed-on: https://chromium-review.googlesource.com/627636
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47554}
Due to shortcuts we take on the RegExp.p[@@split] fast path (we don't allocate
a new instance), we need to send sticky regexps to the slow path.
The problem is a slight impedance mismatch between the spec and our fast-path
implementation.
Spec: Creates a new regexp instance `splitter` that is guaranteed to be sticky,
uses `splitter.lastIndex` to advance the search range, advances by itself using
AdvanceStringIndex if `splitter` did not match at the current position.
Our fast path: Uses the given regexp instance and does not modify stickyness,
uses last_match_info to advance search range, returns (and assumes no more
matches) once RegExpExecInternal fails to match.
This is fine if the given regexp is non-sticky, since 1. the value of lastIndex
is ignored, and 2. non-sticky regexps match if a match is found anywhere in the
string, not just exactly at the current lastIndex.
Sticky regexps though are a problem. If no match is found exactly at the current
position, @@split assumes no more matches and exits.
In a follow-up, we could explore other options, such as allocating a new
instance or saving/restoring flags and lastIndex.
Bug: v8:6706
Change-Id: I6da2266df72b2f80f00c1ce3cd7c8655de91f680
Reviewed-on: https://chromium-review.googlesource.com/626065
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47543}
This makes sure that shift expressions (not wrapped in parentheses) can
appear as part of the index in a valid heap access expression. Only the
last operand of a sequence of shift expressions is taken into account
when validating the heap access.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-6700
BUG=v8:6700,chromium:754751
Change-Id: Icc7a71bd64461da4d3daea41b995964e3dfc6dc6
Reviewed-on: https://chromium-review.googlesource.com/623811
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47497}
If the elements fixed array is large enough, it must be allocated in
large-object space. This fixes two cases in which we'd incorrectly
assume elements fits into new space.
There are potentially quite a few other spots affected by a similar
issue, and we should find a more robust solution. See also:
crbug.com/636391.
Bug: v8:6716
Change-Id: I91f09355ac6b7cf399e13cc21d34113a506e58fb
Reviewed-on: https://chromium-review.googlesource.com/623808
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47495}
Before 983eec8979, RewritableExpressions
which had been queued for destructuring assignment rewriting but which
turned out to be part of a binding pattern in arrow function parameters
would be silently ignored by the PatternRewriter. After that CL, they
failed with a DCHECK.
This patch reverts to the previous behavior, with a TODO to handle this
in a better way by dequeuing RewritableExpressions that turned out
to be part of an inner arrow function.
Bug: chromium:756332
Change-Id: I0a9bf51499940c944034d9a8128e89950de38059
Reviewed-on: https://chromium-review.googlesource.com/619506
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47435}
The crash used to happen when trap is a Smi.
Bug: chromium:756608
Change-Id: I0a6f0328afc64d8e521b5b370a291f9aef6b08d0
Reviewed-on: https://chromium-review.googlesource.com/620647
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Maya Lekova <mslekova@google.com>
Cr-Commit-Position: refs/heads/master@{#47429}
This is a reland of 21da12a983
Original change's description:
> [Compiler] Remove CompileDebugCode and EnsureBytecode and replace with Compile
>
> Removes the Compiler::CompileDebugCode and Compiler::EnsureBytecode functions
> and replaces them with a Compiler::Compile(Handle<SharedFunctionInfo> shared)
> function. The code in compiler.cc is refactored to use this function to compile
> the SharedFunctionInfo when compiling a JSFunction.
>
> Also does some other cleanup:
> - Removes CompileUnoptimizedFunction and inlines into new Compiler function
> - Moves code to create top level SharedFunctionInfo into CompilerTopLevel and
> out of FinalizeUnoptimizedCompile.
>
> BUG=v8:6409
>
> Change-Id: Ic54afcd8eb005c17f3ae6b2355060846e3091ca3
> Reviewed-on: https://chromium-review.googlesource.com/613760
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47394}
TBR=yangguo@chromium.orgTBR=jarin@chromium.org
Bug: v8:6409
Change-Id: If2eae66a85f129e746a5ca5c04935540f3f86b04
Reviewed-on: https://chromium-review.googlesource.com/618886
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47399}
This reverts commit 21da12a983.
Reason for revert: Failing on arm64 simulator
Original change's description:
> [Compiler] Remove CompileDebugCode and EnsureBytecode and replace with Compile
>
> Removes the Compiler::CompileDebugCode and Compiler::EnsureBytecode functions
> and replaces them with a Compiler::Compile(Handle<SharedFunctionInfo> shared)
> function. The code in compiler.cc is refactored to use this function to compile
> the SharedFunctionInfo when compiling a JSFunction.
>
> Also does some other cleanup:
> - Removes CompileUnoptimizedFunction and inlines into new Compiler function
> - Moves code to create top level SharedFunctionInfo into CompilerTopLevel and
> out of FinalizeUnoptimizedCompile.
>
> BUG=v8:6409
>
> Change-Id: Ic54afcd8eb005c17f3ae6b2355060846e3091ca3
> Reviewed-on: https://chromium-review.googlesource.com/613760
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47394}
TBR=rmcilroy@chromium.org,yangguo@chromium.org,jarin@chromium.org,leszeks@chromium.org
Change-Id: I4ba63e82417a185f1528ff2633eb6c8872fbbfe5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6409
Reviewed-on: https://chromium-review.googlesource.com/618687
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47397}
Removes the Compiler::CompileDebugCode and Compiler::EnsureBytecode functions
and replaces them with a Compiler::Compile(Handle<SharedFunctionInfo> shared)
function. The code in compiler.cc is refactored to use this function to compile
the SharedFunctionInfo when compiling a JSFunction.
Also does some other cleanup:
- Removes CompileUnoptimizedFunction and inlines into new Compiler function
- Moves code to create top level SharedFunctionInfo into CompilerTopLevel and
out of FinalizeUnoptimizedCompile.
BUG=v8:6409
Change-Id: Ic54afcd8eb005c17f3ae6b2355060846e3091ca3
Reviewed-on: https://chromium-review.googlesource.com/613760
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47394}
In the case of a function constructor or eval, we create a new script
object which doesn't have a script name. In this case, we traverse
upwards on the list of SFI's through script->eval_from_shared() to get
the outermost script that was not an eval script and get the script
name from that script.
Bug: chromium:746909, v8:6683, v8:5785
Change-Id: I430459f632a0e3b18fc3111a5cf1c00cedb9f520
Reviewed-on: https://chromium-review.googlesource.com/606701
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47352}
It expected its argument to be a JSFunction, but fuzzer tests can
pass anything. Non-JSFunction arguments should just silently be
ignored, just like similar CF-whitelisted runtime functions do.
Bug: chromium:754177
Change-Id: I41b29528bbe72f24b3d84f021b22602160769d26
Reviewed-on: https://chromium-review.googlesource.com/610706
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47316}
When lazy-compiling, it is important we reconstitute the
ModuleEnv accurately. Besides addressing a bug, this change
also does away with the need to relocate memory and globals
parameters (in lazy compilation), by using "the right ones" upfront.
Bug: chromium:753496
Change-Id: I1412a499f05d02d49319fced1b3047698328f3b5
Reviewed-on: https://chromium-review.googlesource.com/609376
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47280}
This is in preparation to the removal of the FullCodeGenerator, we no
longer need the ability to stress the underlying implementation.
R=rmcilroy@chromium.org
BUG=v8:6409
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Iad3177d6de4a68b57c12a770b6e85ed7a9710254
Reviewed-on: https://chromium-review.googlesource.com/584747
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47276}
This changes the DCHECK (which could correctly fail) to be part of the
conditional that checks if we're in an async function.
Bug: chromium:751789
Change-Id: I3b8c1239ac93190055622c41fa1122e83b69d255
Reviewed-on: https://chromium-review.googlesource.com/607356
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47261}
Because SizeFor only returns aligned values, when we check values
returned there against kMaxSize, they can be larger if they were
rounded up.
It wasn't possible to write a test for the 2-byte version that didn't
regularly OOM.
Bug: chromium:752764
Change-Id: Id2f387449e0fafe633a2fde1ac728be31487f62d
Reviewed-on: https://chromium-review.googlesource.com/607935
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47252}
This fixes a bug affecting module namespace objects, which are currently
implemented using native accessors.
Bug: v8:6681, v8:1569
Change-Id: I6a678652573a332c47315497d927c390d9da0926
Reviewed-on: https://chromium-review.googlesource.com/606027
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47238}
This avoid introduction of {TypeGuard} nodes during load elimination.
Such type guard could lead to contradicting type information where a
constant {NumberConstant} node was guarded to have {ExternalPointer}
type, which would lead to an impossible constraint on representation
selection.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-752826
BUG=chromium:752826
Change-Id: Ida3815af24ccc8a48474b8d66117b9718f61adda
Reviewed-on: https://chromium-review.googlesource.com/605547
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47218}
This code appears to have been wrong forever, as it only
threw in strict mode (presumably predating ES2015 const).
In order to get exactly the right behavior, special
handling of sloppy named function expressions is required.
Rather than polluting PropertyAttributes with another
dummy value, this CL simply adds a bool output argument
to Context::Lookup to indicate that case.
Bug: v8:6677
Change-Id: I34daa5080d291808f10cbaefc91d716f0b22963b
Reviewed-on: https://chromium-review.googlesource.com/602690
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47207}
The ConstructFunctionForwardVarargs and ConstructForwardVarargs
builtins, which are used when inlining the Reflect.construct
builtin into TurboFan optimized code, didn't properly check the
new.target parameter whether it's a constructor.
Bug: chromium:752481
Change-Id: I9b8f8c429d6eaed0ff8d27fc3f6b52eb906766a2
Reviewed-on: https://chromium-review.googlesource.com/604187
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47206}
This fixes a missing fast-path check in the code-stub implementation of
the {Array.prototype.filter} method. Appending to the target JSArray is
only correct if the underlying length did not change.
R=jgruber@chromium.org
TEST=mjsunit/regress/regress-6657
BUG=v8:6657
Change-Id: Ida8d3511485b649b70d9a4b161742d494ebe4dac
Reviewed-on: https://chromium-review.googlesource.com/600467
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47156}
