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}
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}
This delays removing dead loop's loop exits after we iterate all uses of
the loop. That way, we avoid mutating the use collection while iterating
it.
Bug: chromium:803022
Change-Id: I17462dd82c3cb78f2f630e5db81d8ccdcc517d83
Reviewed-on: https://chromium-review.googlesource.com/878329
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50813}
This CL moves allocations in array-multiple-receiver-maps.js
to prevent gc fuzzing from cleaning out code objects, which
will mess with assertOptimized in the test.
Bug: v8:7338
Change-Id: I9ee88cf5518307ff12302df2fdaca5258c23b779
Reviewed-on: https://chromium-review.googlesource.com/880957
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50809}
This fixes a corner-case where deserialization of a module containing
multiple exported functions of the same signature forgot to properly
unprotect the code-space. Test coverage has been added.
R=clemensh@chromium.org
TEST=mjsunit/wasm/compiled-module-serialization
BUG=chromium:804767
Change-Id: I0082303db19bcc14c4de30f29d604665e281d79d
Reviewed-on: https://chromium-review.googlesource.com/880844
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50799}
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}
The predicatable mode sets --single-threaded flag, which disables
--wasm-async-compilation. The test relies on async compilation.
Change-Id: I49dae829506c69f21f148cc9c9565c136abcda42
Reviewed-on: https://chromium-review.googlesource.com/880842
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50793}
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 avoids the call to the StringCharCodeAt builtin from
within TurboFan optimized code and instead emits a loop
that does the character load. This (together with previously
reverted CL to the JSCallReducer) almost completely recovers
the performance regression caused when we shipped TurboFan.
Without untrusted code mitigations the benchmark goes from
580ms to roughly 490ms, and with the patch to the JSCallReducer
the time goes down to 280ms, which is very close to what we
had with Crankshaft.
This also renames the LoadFromString helper method in the
EffectControlLinearizer to LoadFromSeqString to make it
clear what it does.
Bug: v8:7326
Change-Id: I6c77209ae01a3eacbd1e8fd40e4ad842eaf1999a
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/876102
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50725}
Until now, String.prototype.{trimLeft,trimRight} were non-standard
language extensions, required for Web compatibility.
The proposal at https://github.com/tc39/proposal-string-left-right-trim
standardizes this functionality as String.prototype.{trimStart,trimEnd},
and defines String.prototype.{trimLeft,trimRight} as aliases for
backwards compatibility.
This patch implements that proposal behind the --harmony-string-trimming
flag.
Bug: v8:6530
Change-Id: Id21e624c12a79e6b782efb049a48901b9da7db71
Reviewed-on: https://chromium-review.googlesource.com/867044
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50717}
This is the v8 side of changes; blink changes are at https://chromium-review.googlesource.com/c/chromium/src/+/809228
BUG=chromium:716320
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ia77764aed09dd609bf2304fe3c392a0e8ee16334
Reviewed-on: https://chromium-review.googlesource.com/847337
Reviewed-by: v8 autoroll <v8-autoroll@chromium.org>
Cr-Original-Commit-Position: refs/heads/6.5.123@{#1}
Cr-Original-Branched-From: 2a8e1e4a9470bc3a92c58fde069901497a3f3fed-refs/heads/master@{#50331}
Reviewed-on: https://chromium-review.googlesource.com/854395
Commit-Queue: Malcolm White <malcolmwhite@google.com>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50699}
- Add Map, WeakMap, Set, and WeakSet initial prototype maps to native context.
- Set and WeakSet constructors check whether prototype map differs from initial
before choosing the fast path.
Bug: chromium:798026
Change-Id: I5f9cc2463f89e17f06a66b565c625fce133d01fb
Reviewed-on: https://chromium-review.googlesource.com/853698
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50691}
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}
The WebAssembly JS API specification [1] covers the JS-visible side-effects
of executing a grow_memory operation and states that a successful
grow operation should always detach any prior array buffer.
[1] https://github.com/WebAssembly/spec/blob/master/document/js-api/index.bsR=mstarzinger@chromium.org,gdeepti@chromium.org
Bug:
Change-Id: Ib9232e01209ba546c0bba1c9408c92da60ff6d92
Reviewed-on: https://chromium-review.googlesource.com/860011
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50627}
We don't currently inline array builtins if we detect any side effects
between the load of the receiver map and the call to the builtin.
The introduction of a map check allows us to be more permissive.
Bug: v8:7250
Change-Id: I6b3f9243f6506eff45c0d727c47a7e8cb8765640
Reviewed-on: https://chromium-review.googlesource.com/849005
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50620}
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}
The fast variants set got the same as no variants after crankshaft
deprecation and there is no plan to extend it again. Hence we remove
the modifier now.
TBR=yangguo@chromium.org
Bug: v8:7264
Change-Id: Ib577542741841b5b9542327b90afea8d5a62c879
Reviewed-on: https://chromium-review.googlesource.com/866496
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50566}
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}
It was shipped in Chrome 63.
Bug: v8:5855
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Icc00b8300622d1c7b5662be8ac5e425b9781f666
Reviewed-on: https://chromium-review.googlesource.com/858381
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50558}
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}
https://github.com/tc39/ecma262/pull/988 gained concensus during the
september 2017 TC39 meetings. This moves the load of the "next" method
to the very beginning of the iteration protocol, rather than during
each iteration step.
This impacts:
- yield*
- for-of loops
- spread arguments
- array spreads
In the v8 implementation, this also affects async iteration versions of
these things (the sole exception being the Async-From-Sync iterator,
which requires a few more changes to work with this, likely done in a
followup patch).
This change introduces a new AST node, ResolvedProperty, which can be used
as a callee by Call nodes to produce the same bytecode as Property calls,
without observably re-loading the property. This is used in several
AST-desugarings involving the iteration protocol.
BUG=v8:6861, v8:5699
R=rmcilroy@chromium.orgTBR=neis@chromium.org, adamk@chromium.org
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I9685db6e85315ba8a2df87a4537c2bf491e1e35b
Reviewed-on: https://chromium-review.googlesource.com/857593
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50518}
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}
The fast-path of S.p.charAt/charCodeAt wrongly truncates the index,
i.e. charAt(k + 4294967295) yields the same as charAt(k-1). This CL
fixes this behaviour, at the cost of not providing a fast-path for
charAt(1.1), i.e. if charAt/charCodeAt is called with a Number.
Bug: chromium:800594
Change-Id: Ic8e749380d3118f0c9469eb626e81bf72cf09fec
Reviewed-on: https://chromium-review.googlesource.com/860003
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50497}
It was included accidentally. It is not in the ES spec, nor is it
provided by any other browser.
BUG=chromium:793095
Change-Id: I2370a6d2b8d14def8dbd47ff4a1ffb4f5f65f097
Reviewed-on: https://chromium-review.googlesource.com/815757
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50491}
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}
This reverts commit bf4cc9ee15.
Reason for revert: Breaks windows with msvc and linux with gcc
https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20msvc/builds/841https://build.chromium.org/p/client.v8/builders/V8%20Linux%20gcc%204.8/builds/17265
Original change's description:
> [esnext] load `iterator.next` only once at beginning of iteration
>
> https://github.com/tc39/ecma262/pull/988 gained concensus during the
> september 2017 TC39 meetings. This moves the load of the "next" method
> to the very beginning of the iteration protocol, rather than during
> each iteration step.
>
> This impacts:
>
> - yield*
> - for-of loops
> - spread arguments
> - array spreads
>
> In the v8 implementation, this also affects async iteration versions of
> these things (the sole exception being the Async-From-Sync iterator,
> which requires a few more changes to work with this, likely done in a
> followup patch).
>
> This change introduces a new AST node, ResolvedProperty, which can be used
> as a callee by Call nodes to produce the same bytecode as Property calls,
> without observably re-loading the property. This is used in several
> AST-desugarings involving the iteration protocol.
>
> BUG=v8:6861, v8:5699
> R=rmcilroy@chromium.org, neis@chromium.org, adamk@chromium.org
>
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Ib81106a0182687fc5efea0bc32302ad06376773b
> Reviewed-on: https://chromium-review.googlesource.com/687997
> Commit-Queue: Caitlin Potter <caitp@igalia.com>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50452}
TBR=rmcilroy@chromium.org,adamk@chromium.org,neis@chromium.org,caitp@igalia.com,caitp@chromium.org
Change-Id: I1797c0d596dfd6850d6f0f505f591a7a990dd1f1
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6861, v8:5699
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/857616
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50454}
https://github.com/tc39/ecma262/pull/988 gained concensus during the
september 2017 TC39 meetings. This moves the load of the "next" method
to the very beginning of the iteration protocol, rather than during
each iteration step.
This impacts:
- yield*
- for-of loops
- spread arguments
- array spreads
In the v8 implementation, this also affects async iteration versions of
these things (the sole exception being the Async-From-Sync iterator,
which requires a few more changes to work with this, likely done in a
followup patch).
This change introduces a new AST node, ResolvedProperty, which can be used
as a callee by Call nodes to produce the same bytecode as Property calls,
without observably re-loading the property. This is used in several
AST-desugarings involving the iteration protocol.
BUG=v8:6861, v8:5699
R=rmcilroy@chromium.org, neis@chromium.org, adamk@chromium.org
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ib81106a0182687fc5efea0bc32302ad06376773b
Reviewed-on: https://chromium-review.googlesource.com/687997
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50452}
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}
This adds support for direct calls in Liftoff.
Drive-by: Fix / extend two tests for calls which were helpful for
developing this CL.
R=ahaas@chromium.org
Bug: v8:6600
Change-Id: I20a98d9dd330da9a020c8c9b5c10b04e94af684d
Reviewed-on: https://chromium-review.googlesource.com/847579
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50427}
This is a reland of 9c79b37aa7
Original change's description:
> [wasm] use allocation tracker to track reserved address space
>
> This is a step towards falling back on bounds checks when there are too many
> guarded Wasm memories.
>
> Bug: v8:7143
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: I01916cbdd5ddb08fe1d946ab83b801f37a8fe1c6
> Reviewed-on: https://chromium-review.googlesource.com/832944
> Commit-Queue: Eric Holk <eholk@chromium.org>
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50390}
Bug: v8:7143
Change-Id: Iaf0d22d300a3f2da22649552a17162dcf7bc608b
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/853142
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50418}
This is just a rebased version of
https://chromium-review.googlesource.com/c/v8/v8/+/571453 with
no functional changes
Bug: v8:6889
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ia082cc09ca527505b288ac88e68e0b74eae94765
Reviewed-on: https://chromium-review.googlesource.com/849423
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50417}
The tests generated by --wasm-fuzzer-gen-test did not encode the locals
of functions yet. This CL fixes that.
A bit of care has to be taken to ensure that the locals are generated
in exactly the same order as in the module generated by the fuzzer.
This requires calling {addLocals} several times.
R=ahaas@chromium.org
Change-Id: I95237b0baef0731b6c164fddc8f12fa6f478e220
Reviewed-on: https://chromium-review.googlesource.com/848832
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50402}
This reverts commit 9c79b37aa7.
Reason for revert: breaks TSAN
https://logs.chromium.org/v/?s=chromium%2Fbb%2Fclient.v8%2FV8_Linux64_TSAN%2F18959%2F%2B%2Frecipes%2Fsteps%2FCheck%2F0%2Flogs%2Finstance-gc%2F0
Original change's description:
> [wasm] use allocation tracker to track reserved address space
>
> This is a step towards falling back on bounds checks when there are too many
> guarded Wasm memories.
>
> Bug: v8:7143
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: I01916cbdd5ddb08fe1d946ab83b801f37a8fe1c6
> Reviewed-on: https://chromium-review.googlesource.com/832944
> Commit-Queue: Eric Holk <eholk@chromium.org>
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50390}
TBR=bbudge@chromium.org,gdeepti@chromium.org,eholk@chromium.org,eholk@google.com
Change-Id: I207b9466377ba50be17794e71407b0ebc8eb88e2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7143
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/853140
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50392}
This is a step towards falling back on bounds checks when there are too many
guarded Wasm memories.
Bug: v8:7143
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I01916cbdd5ddb08fe1d946ab83b801f37a8fe1c6
Reviewed-on: https://chromium-review.googlesource.com/832944
Commit-Queue: Eric Holk <eholk@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50390}
Create a new function kind for initializer functions and ban arguments
if used in such a function.
Bug: v8:5367, v8:7183
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Id3089e587b3d6a25f27224045f250e032b831818
Reviewed-on: https://chromium-review.googlesource.com/850547
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50369}
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}
DeadValue was a constant node of type None. This is unsound in the
presence of re-scheduling. This CL adds a value input to DeadValue,
which preserves the dependency on the original node of type None.
This reland addresses the bug that the EffectControlLinearizer could destroy dependencies of DeadValue by attaching DeadValue nodes to the effect chain in the EffectControlLinearizer.
Bug: chromium:796041 chromium:798938
Change-Id: If47b54a7986d257eb63b437f855769b503679ff5
Reviewed-on: https://chromium-review.googlesource.com/850392
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50360}
Array.prototype.{forEach, filter, map, every} get this support
with the help of a new opcode NumberIsFloat64Hole.
Bug: v8:1956
Change-Id: Ic6a785590cec66bae4c1462c19d6843c0aa5473b
Reviewed-on: https://chromium-review.googlesource.com/847435
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50358}
Add an early exit if the control op is Dead to prevent failing the
DCHECK.
BUG=chromium:797596, v8:5940, v8:3018
R=bmeurer@chromium.org, jarin@chromium.org
Change-Id: I6090380ea69c3205740b6c7a41d7c066d18d6a9f
Reviewed-on: https://chromium-review.googlesource.com/844978
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50312}
This patch implements https://github.com/tc39/proposal-class-fields/pull/65
and https://github.com/tc39/proposal-static-class-features/ by
splitting out instance and static field declarations into separate
flags for the separate proposals. Instance class fields is currently
at Stage 3 whereas static class fields is currently at Stage 2.
Bug: v8:5367
Change-Id: I133c945fd0b22dc5718c7bb61b10f22348087acd
Reviewed-on: https://chromium-review.googlesource.com/839778
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50293}
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}
This patch updates the instruction selector and code generator to pad arguments
for arm64 and drop an even number of slots when dropping the arguments. It also
updates the builtins that handle arguments. These changes need to be made at
the same time.
It also adds some tests for forwarding varargs, as this was affected by the
builtin changes and the existing tests did not catch all issues.
Bug: v8:6644
Change-Id: I81318d1d1c9ab2568f84f2bb868d2a2d4cb56053
Reviewed-on: https://chromium-review.googlesource.com/829933
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50259}
When shared memory is defined in the module bytes, and not imported/exported
underlying memory should be a SharedArrayBuffer. This was missing in the
allocate flow during instantiation. Fixed to use a SharedArrayBuffer.
BUG=v8:6532
Change-Id: Ic62ed3fd578a0e03124ee40b273e6a4ea474bba4
Reviewed-on: https://chromium-review.googlesource.com/835348
Reviewed-by: Eric Holk <eholk@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50255}
In a benchmark that I'm looking at, the numbers quickly overflow our
current limit.
This patch increases kMaxLength to the greatest value that's possible
without requiring further code changes.
Bug: v8:6791
Change-Id: I7a0d126dcd566d536375a294fa4dcf10b8823ed7
Reviewed-on: https://chromium-review.googlesource.com/833876
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50240}
Previously, FrameFunctionIterator::next() assumed that the frame summary
was non-empty. It's now possible for the list not to be empty, if the
JS microtask pump invokes a builtin function which uses
FrameFunctionIterator directly. While this is unlikely to show up in
real world code, it is necessary to handle it to prevent crashes.
BUG=chromium:794744
R=mstarzinger@chromium.org, cbruni@chromium.org, verwaest@chromium.org
Change-Id: Ie95c2228544f57730d1c6c1ff955b2c94ff1c06b
Reviewed-on: https://chromium-review.googlesource.com/833266
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#50221}
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}
This CL passes feedback from the element kind deopt points
in Array.push to the deoptimizer. If the deopt points are
triggered, further speculation on Array.push is disallowed.
Bug: v8:7127, v8:7204
Change-Id: Ie91dee598bd8b8797110c8f468406327226893a4
Reviewed-on: https://chromium-review.googlesource.com/831523
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50171}
Make sure that a continue still executed the increment part of a for
loop by adding another nested block for the body, which is the break
target for a continue in the body. The increment code lives outside
this block, in the original loop.
R=bradnelson@chromium.orgCC=mstarzinger@chromium.org
Bug: chromium:788916
Change-Id: I178b874ffac16d9237a0f4da097d2742bd93335a
Reviewed-on: https://chromium-review.googlesource.com/832447
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50169}
See https://github.com/tc39/proposal-regexp-named-groups/pull/40.
The spec is being changed to always create a 'groups' property on
regexp result objects. Its value is undefined if no named captures
exist, and the object containing named captures otherwise.
Bug: v8:7192, v8:5437
Change-Id: I1fb00ffc186c7effd84b5692dcbed420581855c3
Reviewed-on: https://chromium-review.googlesource.com/829137
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50154}
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}
Add feedback to GrowFastElements operator and thread it
through to the deoptimize node it the lowering. The CL
uses the feedback to allow Array.push to disable speculation
if the grow operation deopts.
Bug: v8:7127, v8:7204
Change-Id: Ib5850a93759b9194c0fc2f191f6adf5d49cb7f55
Reviewed-on: https://chromium-review.googlesource.com/827128
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50145}
Support inlining Array.prototype.findIndex in Turbofan.
Depending on array size, quick benchmarks show a >2x
improvement: https://github.com/peterwmwong/v8-perf/blob/master/array-find-findIndex-tf/README.md
Bug: chromium:791045, v8:1956, v8:7165
Change-Id: I250554885f924c97b0072e09ee289713df5cbe63
Reviewed-on: https://chromium-review.googlesource.com/824382
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50133}
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}
This reverts commit 917b9cb9fc.
In this CL, we canonicalize the fixed array when allocating storage for
empty fixed array. During initialization, we also make sure that we do
not write to the empty fixed array. This is quite hacky, but it
seems to be the least intrusive change.
Bug: chromium:793863
Change-Id: I1449ebac7c1e390467566a759bf70e7e2fabda31
Reviewed-on: https://chromium-review.googlesource.com/827013
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50119}
This CL also adds support for "lookup on dictionary receivers" to store ICs.
Bug: v8:7206, v8:5561
Change-Id: Icebbc2d52c71f5d25b43f2f2a8adf674e4ec2cbc
Reviewed-on: https://chromium-review.googlesource.com/819232
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50113}
The IsPromise brand check is now replaced with an IsObject check.
The spec was changed here:
a1628886f8
Bug: v8:7095
Change-Id: I5668083c888f9efcdfc1491c919c810c75d73ac7
Reviewed-on: https://chromium-review.googlesource.com/826606
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50108}
Add support for disallowing speculation upon deoptimize from
a CheckBound node, and use this in the case of array builtins
in js-call-reducer to prevent deoptimization loops.
Bug: v8:7127
Change-Id: I04cf655b10178d2938d2f0ee6b336601fab6463b
Reviewed-on: https://chromium-review.googlesource.com/822195
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50097}
Port bd732f7ddd
Original Commit Message:
The original CL introduced a test which uses a random number generator.
I disable the test for now, which is okay because this CL adds to a
work-in-progress feature anyways, and I will fix the problem in another
CL.
Original description:
Add the ability to return (multiple) return values on the stack:
- Extend stack frames with a new buffer region for return slots.
This region is located at the end of a caller's frame such that
its slots can be indexed as caller frame slots in a callee
(located beyond its parameters) and assigned return values.
- Adjust stack frame constructon and deconstruction accordingly.
- Extend linkage computation to support register plus stack returns.
- Reserve return slots in caller frame when respective calls occur.
- Introduce and generate architecture instructions ('peek') for
reading back results from return slots in the caller.
- Aggressive tests.
- Some minor clean-up.
So far, only ia32 and x64 are implemented.
R=ahaas@chromium.org, joransiu@ca.ibm.com, jbarboza@ca.ibm.com
BUG=
LOG=N
Change-Id: I8d63286aa5af5f52cc2eeaf2adeee13d0ff19e7d
Reviewed-on: https://chromium-review.googlesource.com/823084
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50091}
This ensures that MigrateFastToFast does not overflow the length of the
property array.
Bug: chromium:789393
Change-Id: I77adc319c1c8c469ea482bad35ead8661d535192
Reviewed-on: https://chromium-review.googlesource.com/824167
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50086}
- All testcase/testsuite/variant generator subclasses renamed to
just TestCase/TestSuite/VariantGenerator since they're private
implementation.
- All `testcase` variables renamed to `test` to not conflict with
a module name.
- No more two statements in the same line.
- Removed some unused testsuite methods.
Bug: v8:6917
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I7710f3419f738a5f9ddca73765dd2cad2e35b952
Reviewed-on: https://chromium-review.googlesource.com/823964
Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michał Majewski <majeski@google.com>
Cr-Commit-Position: refs/heads/master@{#50076}
This disallows speculation after deoptimization from any of
Array.{forEach,map,filter,find} due to CheckMap fails. Such
CheckMap fails happen if the builtins' function argument
causes the map of the array to change. The js-call-lowering
refrains from optimizing builtins for which speculation was
disallowed.
Bug: v8:6898, v8:7127
Change-Id: Ied6696f8fb023ee404fb82e9d37bfb061f293854
Reviewed-on: https://chromium-review.googlesource.com/819354
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50069}
- create testcase subclass for each test
- move get_command, get_source from suite to test
- promises-aplus tests are broken
- moving expected outcomes etc. is still in progress
Bug: v8:6917
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I006e64ecf51dda95c41dff88c68b24f17a638566
Reviewed-on: https://chromium-review.googlesource.com/798331
Commit-Queue: Michał Majewski <majeski@google.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50065}
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}
The original CL introduced a test which uses a random number generator.
I disable the test for now, which is okay because this CL adds to a
work-in-progress feature anyways, and I will fix the problem in another
CL.
Original description:
Add the ability to return (multiple) return values on the stack:
- Extend stack frames with a new buffer region for return slots.
This region is located at the end of a caller's frame such that
its slots can be indexed as caller frame slots in a callee
(located beyond its parameters) and assigned return values.
- Adjust stack frame constructon and deconstruction accordingly.
- Extend linkage computation to support register plus stack returns.
- Reserve return slots in caller frame when respective calls occur.
- Introduce and generate architecture instructions ('peek') for
reading back results from return slots in the caller.
- Aggressive tests.
- Some minor clean-up.
So far, only ia32 and x64 are implemented.
Change-Id: I8b03fc4e53946daaa0e14a34603f4824a04fad7e
Reviewed-on: https://chromium-review.googlesource.com/819557
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50031}
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}
Some refactor moved from
https://chromium-review.googlesource.com/c/v8/v8/+/798331.
Bug: v8:6917
Change-Id: I8cae6cfca7a0d7d8e234052c0ab0bfe252355e60
Reviewed-on: https://chromium-review.googlesource.com/819550
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50020}
This reverts commit 1e49864fa7.
Reason for revert: Crashing test on the waterfall https://logs.chromium.org/v/?s=chromium%2Fbb%2Fclient.v8%2FV8_Linux_gcc_4.8%2F16871%2F%2B%2Frecipes%2Fsteps%2FCheck%2F0%2Flogs%2FReturnMultipleRandom%2F0
Original change's description:
> [turbofan] Implement on-stack returns (Intel)
>
> Add the ability to return (multiple) return values on the stack:
>
> - Extend stack frames with a new buffer region for return slots.
> This region is located at the end of a caller's frame such that
> its slots can be indexed as caller frame slots in a callee
> (located beyond its parameters) and assigned return values.
> - Adjust stack frame constructon and deconstruction accordingly.
> - Extend linkage computation to support register plus stack returns.
> - Reserve return slots in caller frame when respective calls occur.
> - Introduce and generate architecture instructions ('peek') for
> reading back results from return slots in the caller.
> - Aggressive tests.
> - Some minor clean-up.
>
> So far, only ia32 and x64 are implemented.
>
> Change-Id: I9532ad13aa307c1dec40548c5b84600fe2f762ce
> Reviewed-on: https://chromium-review.googlesource.com/766371
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49994}
TBR=titzer@chromium.org,rossberg@chromium.org,ahaas@chromium.org
Change-Id: Ib257e92448942f8ef07d5ef246f9381f4784f014
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/819637
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50000}
Add the ability to return (multiple) return values on the stack:
- Extend stack frames with a new buffer region for return slots.
This region is located at the end of a caller's frame such that
its slots can be indexed as caller frame slots in a callee
(located beyond its parameters) and assigned return values.
- Adjust stack frame constructon and deconstruction accordingly.
- Extend linkage computation to support register plus stack returns.
- Reserve return slots in caller frame when respective calls occur.
- Introduce and generate architecture instructions ('peek') for
reading back results from return slots in the caller.
- Aggressive tests.
- Some minor clean-up.
So far, only ia32 and x64 are implemented.
Change-Id: I9532ad13aa307c1dec40548c5b84600fe2f762ce
Reviewed-on: https://chromium-review.googlesource.com/766371
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49994}
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}
This relands commit e71b802279.
This can now back in as the fix for chromium:787301 had enough time to
be tested in Canary.
Original change's description:
> [deoptimizer] Staged materialization of objects.
>
> The existing object materialization in the deoptimizer has the following problems:
>
> - Objects do not necessarily verify during materialization (because during the
> depth first walk we might have inconsistent objects).
>
> - Stack can overflow (because we just materialize using recursive calls).
>
> - We generalize object fields.
>
>
> This CL re-implements the materialization algorithm to solve this problem. The
> new implementation creates the objects in two steps:
>
> 1. We allocate space for all the objects. In general, we allocate ByteArrays
> of the right size. For leaf objects that cannot participate in cycles,
> we build and initialize the materialized objects completely.
>
> For JS objects, we insert markers into the byte array at the positions
> where unboxed doubles are expected.
>
> 2. We initialize all the objects with the proper field values and change the
> map from the ByteArray map to the correct map. This requires some sync
> with the concurrent marker (Heap::NotifyObjectLayoutChange).
>
> When initializing the JS object fields, we make sure that we respect
> the unboxed double marker.
>
> Bug: chromium:770106, v8:3836
> Change-Id: I1ec466a9d19db9538df4ba915516d4c3ca825632
> Reviewed-on: https://chromium-review.googlesource.com/777559
> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49821}
Bug: chromium:770106, v8:3836
Change-Id: Ied6c4e0fbae52713e55ae6dc13794a7521dbb8a5
Reviewed-on: https://chromium-review.googlesource.com/817745
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49982}
This moves the verify-predictable logic from the test runner into
a python wrapper script.
This revealed two more tests that don't print allocations, which are
now skipped.
Bug: v8:7166, v8:7177
Change-Id: Ie4a541cb2a20900414ffe1caf4b3fccc4a5edb52
Reviewed-on: https://chromium-review.googlesource.com/808971
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49964}
Bug: chromium:780819
Change-Id: I07c5ff3cf955edb087a175ea2d71a35e0f520ec3
Reviewed-on: https://chromium-review.googlesource.com/813839
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49953}
This reverts commit 59f221740c.
Reason for revert: android build issue (https://build.chromium.org/p/client.v8.fyi/builders/Android%20Release%20%28Nexus%205X%29/builds/3583)
Original change's description:
> [wasm] Fix wasm-to-wasm handling in 'native heap' lazy compile
>
> Wasm-to-wasm uses a tail call mechanism to reach the target
> function. This means there is no frame for it. This CL ports
> the fix for that for the WasmCodeManager case, akin the current
> fix for the GC case.
>
> Bug: v8:7140
> Change-Id: I04c8a8da1de9cb837a0423493216d2226c53e756
> Reviewed-on: https://chromium-review.googlesource.com/814498
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49942}
TBR=bradnelson@chromium.org,titzer@chromium.org,mtrofin@chromium.org,clemensh@chromium.org
Change-Id: Iae0e43b386f08d2d56aeef70e9fa0af141232023
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7140
Reviewed-on: https://chromium-review.googlesource.com/815180
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49943}
Wasm-to-wasm uses a tail call mechanism to reach the target
function. This means there is no frame for it. This CL ports
the fix for that for the WasmCodeManager case, akin the current
fix for the GC case.
Bug: v8:7140
Change-Id: I04c8a8da1de9cb837a0423493216d2226c53e756
Reviewed-on: https://chromium-review.googlesource.com/814498
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49942}
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}
Exposing the existing Context::AllowCodeGenerationFromStrings(false) API
to the command line.
Bug: v8:7134
Change-Id: I062ccff0b03c5bcf6878c41c455c0ded37a1d743
Reviewed-on: https://chromium-review.googlesource.com/809631
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49911}
- When a global object changes, invalidate its validity cell.
- The global object prototypes don't need to be gathered into an array in InitPrototypeChecks.
Bug: v8:7159
Change-Id: I3621c914d08b83e49e8a391800a92eb53ba19feb
Reviewed-on: https://chromium-review.googlesource.com/808588
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49901}
We cannot remove a speculative operation when it's type relies on it to deopt.
Fix this by only relying on the lowering to remove operations.
Bug: chromium:786521
Change-Id: I2cf45e8d45b76cfeb06e6329f323cade74719124
Reviewed-on: https://chromium-review.googlesource.com/793043
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49882}
For "top digit" (of the result) comparison to be applicable, we must
also check that there are no further digits in the source.
The included regression test flushes out another bug in "TruncateToNBits",
so that gets fixed here too (in contrast to the first landing attempt).
This reverts commit cb9e7af4e5.
Bug: v8:7150
Change-Id: Id631b1ae79e60b8e85ed4667e246a64c46765f2b
Reviewed-on: https://chromium-review.googlesource.com/807348
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49877}
The proper fix would be to make TruncatingUseInfoFromRepresentation
respect tagged signed use representation, but requires extra work
to refine typing for all values that are stored into Smi fields.
Bug: chromium:791245
Change-Id: I83965bcc18a836d2c758a6a8b1477a4aa2c6133d
Reviewed-on: https://chromium-review.googlesource.com/808866
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49870}
- When a dictionary mode prototype changes, invalidate the validity cell.
- The dictionary mode prototypes don't need to be gathered into an array in InitPrototypeChecks.
Bug: v8:7159
Change-Id: I1c7bbaf4b20556f44df18be1463d38fa4fbabe05
Reviewed-on: https://chromium-review.googlesource.com/793732
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49857}
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}
- Removes JS implementation and InnerArrayFind/InnerArrayFindIndex
- Adds TFJ, with TFS for slow continuation path
Some quick benchmarks show ~2x improvement for unoptimized code
and up to 16% improvement against optimized code (diminishes with
larger arrays as iterating dominates).
https://github.com/peterwmwong/v8-perf/blob/master/array-find-findIndex/README.md
Bug: chromium:791045, v8:1956, v8:5049, v8:7165
Change-Id: Ie16252ed495bbd91fe548b16d5ef6764de791a50
Reviewed-on: https://chromium-review.googlesource.com/804704
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49851}
Eventually, we want to fix this also for tagged pointers (tracking bug: https://crbug.com/v8/7162).
Bug: chromium:791245
Change-Id: I93d6deff36cedcc9a4665fab0abe6fffdae9b61b
Reviewed-on: https://chromium-review.googlesource.com/806457
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49850}
This reverts commit e110b59cc7.
Reason for revert: Breaks arm debug on chromebook hardware:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Arm%20-%20debug/builds/5335
Original change's description:
> [bigint] Fix early-return in asIntN
>
> For "top digit" (of the result) comparison to be applicable, we must
> also check that there are no further digits in the source.
>
> Bug: v8:7150
> Change-Id: I6ad317f6f600e11fef59b9907da1055e5586a3a8
> Reviewed-on: https://chromium-review.googlesource.com/804639
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49846}
TBR=jkummerow@chromium.org,neis@chromium.org
Change-Id: I5dae82696d3ecb9602f73a2ff4760ed7bbcef1c5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7150
Reviewed-on: https://chromium-review.googlesource.com/806838
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49847}
For "top digit" (of the result) comparison to be applicable, we must
also check that there are no further digits in the source.
Bug: v8:7150
Change-Id: I6ad317f6f600e11fef59b9907da1055e5586a3a8
Reviewed-on: https://chromium-review.googlesource.com/804639
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49846}
- Implement RunMicrotasks in CSA to prevent a potentially large number
of jumps between C++ and JS code while consuming te queue. Appears to
provide a ~60% speedup in microtask-heavy code, which from limited
testing appears to scale linearly.
The code-stub microtask pump bails out to the old C++ microtask pump
if it encounters a CallHandlerInfo microtask, and remains in C++ for
the remainder of the queue (returning to the JS/stub implementation
after the bailed out queue is exhausted).
- Add a variation of JSEntryStub which enters the new RunMicrotasks code
stub.
- Add a new RunMicrotasks helper to Execution, which uses the
RunMicrotasks entry stub.
Bug:
Change-Id: I4667d4dd633d24455ea5d7cef239da0af1a7365e
Reviewed-on: https://chromium-review.googlesource.com/650486
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49842}
This reverts commit e71b802279.
Reason for revert: Need to have a back-mergeable fix.
Original change's description:
> [deoptimizer] Staged materialization of objects.
>
> The existing object materialization in the deoptimizer has the following problems:
>
> - Objects do not necessarily verify during materialization (because during the
> depth first walk we might have inconsistent objects).
>
> - Stack can overflow (because we just materialize using recursive calls).
>
> - We generalize object fields.
>
>
> This CL re-implements the materialization algorithm to solve this problem. The
> new implementation creates the objects in two steps:
>
> 1. We allocate space for all the objects. In general, we allocate ByteArrays
> of the right size. For leaf objects that cannot participate in cycles,
> we build and initialize the materialized objects completely.
>
> For JS objects, we insert markers into the byte array at the positions
> where unboxed doubles are expected.
>
> 2. We initialize all the objects with the proper field values and change the
> map from the ByteArray map to the correct map. This requires some sync
> with the concurrent marker (Heap::NotifyObjectLayoutChange).
>
> When initializing the JS object fields, we make sure that we respect
> the unboxed double marker.
>
> Bug: chromium:770106, v8:3836
> Change-Id: I1ec466a9d19db9538df4ba915516d4c3ca825632
> Reviewed-on: https://chromium-review.googlesource.com/777559
> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49821}
TBR=ulan@chromium.org,mstarzinger@chromium.org,jarin@chromium.org
Change-Id: I0657fb75330700dd7883c600dacb25676ebb47f9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:770106, v8:3836
Reviewed-on: https://chromium-review.googlesource.com/806160
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49834}
The existing object materialization in the deoptimizer has the following problems:
- Objects do not necessarily verify during materialization (because during the
depth first walk we might have inconsistent objects).
- Stack can overflow (because we just materialize using recursive calls).
- We generalize object fields.
This CL re-implements the materialization algorithm to solve this problem. The
new implementation creates the objects in two steps:
1. We allocate space for all the objects. In general, we allocate ByteArrays
of the right size. For leaf objects that cannot participate in cycles,
we build and initialize the materialized objects completely.
For JS objects, we insert markers into the byte array at the positions
where unboxed doubles are expected.
2. We initialize all the objects with the proper field values and change the
map from the ByteArray map to the correct map. This requires some sync
with the concurrent marker (Heap::NotifyObjectLayoutChange).
When initializing the JS object fields, we make sure that we respect
the unboxed double marker.
Bug: chromium:770106, v8:3836
Change-Id: I1ec466a9d19db9538df4ba915516d4c3ca825632
Reviewed-on: https://chromium-review.googlesource.com/777559
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49821}
Since we have this d8 directory now, we can also use it.
R=machenbach@chromium.org
Bug: v8:7109
Change-Id: I595ceb30e1c9350ad00d5cfaf998e40294602103
Reviewed-on: https://chromium-review.googlesource.com/803214
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49817}
Flush the icache after JIT-ing using the WasmCodeManager. Also, re-enable
tests that were previously failing on Linux ARM.
Bug: v8:7138
Change-Id: I8e18b80dba58df173a2360f8ac365ee5daaf3239
Reviewed-on: https://chromium-review.googlesource.com/802961
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49800}
Adds new API function to request code cache. Earlier code cache was
produced along with compile requests. This new API allows us to request
code cache after executing. Also adds support in the code serializer to
serialize after executing the script.
Bug: chromium:783124,chromium:789694
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Id4e6a967e176e3e979dc4ccb9a37a353c70c3890
Reviewed-on: https://chromium-review.googlesource.com/797036
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49793}
These now pass even when forcing optimization.
TBR=jkummerow@chromium.org
Bug: v8:6791
Change-Id: I4d7c7d37b48e6e970d33474fa7fd637e34b0bda0
Reviewed-on: https://chromium-review.googlesource.com/803374
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49781}
It reflects the semantics of ToBoolean, so it must be adapted for
bigints.
Bug: v8:6791
Change-Id: I18931df21528463dacf5ad50fa8264b1c968c6b5
Reviewed-on: https://chromium-review.googlesource.com/799831
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49776}
This reverts commit e42e7fc800.
Reason for revert: Speculative revert for:
https://crbug.com/v8/7149
Original change's description:
> [objects] No longer create short external strings.
>
> This fixes String::MakeExternal() to bail out if the subject string
> doesn't fit a regular ExternalString, instead of creating a short
> external string. The observation here is that for short external strings
> the overhead of having to have the StringResource plus going to the
> runtime/C++ for each and every character access from JavaScript land
> is probably bigger than the anticipated benefits.
>
> If this turns out to be wrong and there's a real benefit, we should make
> use of ThinStrings instead of having a separate way to represent
> external strings.
>
> Bug: v8:6621, v8:7109, v8:7145
> Change-Id: I4b75da08b82a72027c782a69de9c8eaf3cca1d4d
> Reviewed-on: https://chromium-review.googlesource.com/799750
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49735}
TBR=yangguo@chromium.org,bmeurer@chromium.org
Change-Id: I3f5cfa9ab5c99ddce1d61ede9ed9515cb3936cdd
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6621, v8:7109, v8:7145, v8:7149
Reviewed-on: https://chromium-review.googlesource.com/801675
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49770}
Finally address that long-standing TODO where ConsString allocation in
TurboFan would always go for the two byte map instead of choosing the
one byte map if the inputs are one byte strings.
Bug: v8:5269, v8:7109
Change-Id: Ibcfceaf499ceebef0ef928ebc5f204bcacf29bc0
Reviewed-on: https://chromium-review.googlesource.com/799700
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49744}
This CL fixes an issue with --enable-tracing which was introduced
recently where the tracing file was closed too early. In addition it
adds a test for --enable-tracing to avoid such an issue in the future.
R=machenbach@chromium.org, rmcilroy@chromium.org
Change-Id: I1b3699a4dfbe27230ac1d21d5f6bc7b2ee9ed435
Reviewed-on: https://chromium-review.googlesource.com/796214
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49742}
This test expects certain functions to be optimized, which does not
happen if we force array objects onto the slow path.
Bug: v8:7122
Change-Id: I716954fff564f1c4f0782b3452557ec89a3b4307
Reviewed-on: https://chromium-review.googlesource.com/796860
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49736}
This fixes String::MakeExternal() to bail out if the subject string
doesn't fit a regular ExternalString, instead of creating a short
external string. The observation here is that for short external strings
the overhead of having to have the StringResource plus going to the
runtime/C++ for each and every character access from JavaScript land
is probably bigger than the anticipated benefits.
If this turns out to be wrong and there's a real benefit, we should make
use of ThinStrings instead of having a separate way to represent
external strings.
Bug: v8:6621, v8:7109, v8:7145
Change-Id: I4b75da08b82a72027c782a69de9c8eaf3cca1d4d
Reviewed-on: https://chromium-review.googlesource.com/799750
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49735}
In order to test that we don't repeatedly go through the
WasmCompileLazy runtime function, add a flag to the
LazyCompilationOrchestrator to "freeze" it, i.e. disallow any further
lazy compilation.
In tests, use this flag to first call a method, then freeze lazy
compilation, then call the method again to assert that no further lazy
compilation is triggered.
This test currently fails with --wasm-jit-to-native, so disable it for
that variant.
R=titzer@chromium.orgCC=mtrofin@chromium.org
Bug: v8:7140, chromium:788441, v8:5991
Change-Id: I18a40d302c24041740d8a54351d06ed968f4beec
Reviewed-on: https://chromium-review.googlesource.com/796430
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49734}
In the presence of bigints, this optimization is no longer valid.
Bug: v8:6791
Change-Id: I996ac78f8ae4aef5494dd0089374d04c6db6e72f
Reviewed-on: https://chromium-review.googlesource.com/796070
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49725}
This reverts commit 5d4a090377.
Reason for revert: Speculative revert due to timeouts on testing with
--isolates:
https://build.chromium.org/p/client.v8/builders/V8%20Linux/builds/21889https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20debug/builds/18138
Original change's description:
> Add support to produce code cache after execute.
>
> Adds new API function to request code cache. Earlier code cache was
> produced along with compile requests. This new API allows us to request
> code cache after executing. Also adds support in the code serializer to
> serialize after executing the script.
>
> Bug: chromium:783124
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: Id7b972a2b4c8dcf7a6d9f5ea210890ae968320bd
> Reviewed-on: https://chromium-review.googlesource.com/781767
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49717}
TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org,mythria@chromium.org
Change-Id: Id9e0285e73bbc3ea3908b4b7bbf6599e4f7cd76e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:783124
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/796870
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49722}
This reduces the overhead of calling the builtin.
Quick measurements show >5x improvement. As the
typed array's size grows, iterating dominates
and the performance gap closes.
https://github.com/peterwmwong/v8-perf/blob/master/typedarray-findIndex/README.md
Bug: v8:5929
Change-Id: I27d67776c83cbe28f4f9f5ef479a7eeabf594654
Reviewed-on: https://chromium-review.googlesource.com/792394
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49720}
Adds new API function to request code cache. Earlier code cache was
produced along with compile requests. This new API allows us to request
code cache after executing. Also adds support in the code serializer to
serialize after executing the script.
Bug: chromium:783124
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Id7b972a2b4c8dcf7a6d9f5ea210890ae968320bd
Reviewed-on: https://chromium-review.googlesource.com/781767
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49717}
When exporting an imported wasm function, we generate a js-to-wasm
wrapper which calls the wasm-to-wasm wrapper (which then tail-calls
the WasmCompileLazy stub).
This wasm-to-wasm wrapper also needs to be patched.
R=titzer@chromium.org
Bug: chromium:788441, v8:5991
Change-Id: Ibf27618a0511851cb55714b720fe7299a21c2959
Reviewed-on: https://chromium-review.googlesource.com/795990
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49715}
This addresses two TODOs in Ignition where the Construct and the
ConstructWithSpread bytecodes didn't collect JSBoundFunction
new.target feedback. This is fairly trivial to add now with the
existing machinery and the TurboFan side of this was already fixed
before, so we can leverage the new feedback.
Bug: v8:5267, v8:7109
Change-Id: Iae257836716c14f05f5d301326cbe8b2acaeb38b
Reviewed-on: https://chromium-review.googlesource.com/793048
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49712}
This reverts commit 0269965b37.
Reason for revert: Successfully got some stack traces:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Arm%20-%20debug/builds/5274
Original change's description:
> V8: Temporary run wasm_traps on native arm debug
>
> This will break the bot. This is for getting a stack trace and then
> revert.
>
> TBR=mtrofin@chromium.org
>
> Bug: v8:7138
> Change-Id: I244492ca81f817d64ef7c12e291a6ed9b97e68de
> Reviewed-on: https://chromium-review.googlesource.com/795718
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49698}
TBR=machenbach@chromium.org,mtrofin@chromium.org
Change-Id: Id81736508fd7eb2b9220bf41188f7687c4046960
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7138
Reviewed-on: https://chromium-review.googlesource.com/796290
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49707}
This reduces the overhead of calling the builtin.
Quick measurements show >5x improvement. As the
typed array's size grows, iterating dominates
and the performance gap closes.
https://github.com/peterwmwong/v8-perf/blob/master/typedarray-find/README.md
Bug: v8:5929
Change-Id: Ia74546bb46d446c6161c8956e350d4b5cdc1b328
Reviewed-on: https://chromium-review.googlesource.com/792454
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49706}
In TurboFan we can easily recognize calls to String.prototype.slice
where the start parameter is -1 and the end parameter is either
undefined or not present. These calls either return an empty string if
the input string is empty, or the last character of the input string
as a single character string. So we can just make use of the existing
StringCharAt operator.
This reduces the overhead of the String.prototype.slice calls from
optimized code in the chai test of the web-tooling-benchmark
significantly. We observe a 2-3% improvement on the test.
Bug: v8:6936, v8:7137
Change-Id: Iebe02667446880f5760e3e8c80f8b7cc712df663
Reviewed-on: https://chromium-review.googlesource.com/795726
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49704}
This will break the bot. This is for getting a stack trace and then
revert.
TBR=mtrofin@chromium.org
Bug: v8:7138
Change-Id: I244492ca81f817d64ef7c12e291a6ed9b97e68de
Reviewed-on: https://chromium-review.googlesource.com/795718
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49698}
It was shipped in Chrome 62.
Bug: v8:5546, v8:4829
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I3ac318639f1f7483d4d4f4fe5606387a856be98a
Reviewed-on: https://chromium-review.googlesource.com/777940
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49687}
These tests are failing with OOM.
Bug: v8:6924
Change-Id: I988814350c6199ca5c1976e3f09d3b96e42ec0ff
Reviewed-on: https://chromium-review.googlesource.com/793044
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49686}
And also ensure that it doesn't allocate when that's avoidable.
Bug: v8:6791
Change-Id: Ied2d2c9c5718aed9839f17739d743353cbadee88
Reviewed-on: https://chromium-review.googlesource.com/786170
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49683}
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}
Properly handle known JSBoundFunction instances as targets to
JSConstruct by inlining the construction of the eventual target.
Also if the target is the result of a JSCreateBoundFunction call,
where we can also fold the construction and construct the bound
target function directly instead.
This addresses half of the TODO in the JSConstruct lowering in the
JSCallReducer where so far we didn't handle bound functions.
Bug: v8:5267, v8:7109
Change-Id: I022dc7d4fbbe2c9972472e78a6d64f51e3134c94
Reviewed-on: https://chromium-review.googlesource.com/792947
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49664}
Change the existing uses of the harmony-class-fields flag to
harmony-public-fields so that we can stage this separately
from the upcoming harmony-private-fields to get some
clusterfuzz coverage.
Bug: v8:5367
Change-Id: I76cdefa4faf34eae73d3a5f6d6089cf75677732a
Reviewed-on: https://chromium-review.googlesource.com/792940
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49661}
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}
This extends the typing rule for NumberTrunc to deal with general number
inputs properly, thus addressing a long-standing TODO. We also add test
cases to ensure that the typing rule gets the corner cases for NaN and
-0 right.
Bug: v8:5267, v8:7109
Change-Id: Iedc541a0f4619f37da37ea36940f92472034cdf2
Reviewed-on: https://chromium-review.googlesource.com/792932
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49652}
This extends the typing rule for NumberRound to deal with general number
inputs properly, thus addressing a long-standing TODO. We also add test
cases to ensure that the typing rule gets the corner cases for NaN and
-0 right.
Bug: v8:5267, v8:7109
Change-Id: Ia865ec1d6f8d96f20641bee96891740a9fc6e627
Reviewed-on: https://chromium-review.googlesource.com/792931
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49651}
This extends the typing rule for NumberCeil to deal with general number
inputs properly, thus addressing a long-standing TODO. We also add test
cases to ensure that the typing rule gets the corner cases for NaN and
-0 right.
Bug: v8:5267, v8:7109
Change-Id: I9154e47e58ad106791613db0030051f2a802a981
Reviewed-on: https://chromium-review.googlesource.com/792930
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49650}
Pull most JSTypedArray source arguments onto the fast path.
Same source & target elements-kinds simply call memmove. Other
combinations call directly into C and reuse ElementsAccessor logic.
Only overlapping source & target args with differing elements-kinds
remain on the slow runtime path.
Bug: v8:7123, v8:3590
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I80284b61478b0e3266b8f16bde8a56bd90f080b0
Reviewed-on: https://chromium-review.googlesource.com/788857
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49643}
Implement the new spec behavior that says construction from a neutered
buffer should throw after the ToIndex call on the length argument.
Bug: v8:6216
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I219a107730b53fca639bc813f68f7ddc27e79017
Reviewed-on: https://chromium-review.googlesource.com/789847
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49639}
Previously we only created synthetic variables in the parser and not
in the preparser, causing mismatch in the preparsed scope data.
This patch creates the variables in both parsers.
Bug: v8:5367
Change-Id: I9c511d0b9212bd36816956b06dc204b0b5920e1c
Reviewed-on: https://chromium-review.googlesource.com/789848
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49637}
Within SanitizeImports it is possible that JavaScript code gets executed
therefore we have to open the CodeSpaceMemoryModificationScope after
SanitizeImports.
R=clemensh@chromium.org
Bug: chromium:788469
Change-Id: Ide9bbd4ee4613b28380979d4a6c66d26e6a9406f
Reviewed-on: https://chromium-review.googlesource.com/789936
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49635}
This adds a fast path that avoids the runtime transition for JSArray
source arguments with {packed,holey} {smi,double} elements kinds.
The fast path currently calls straight into C and copies there using
elements accessor logic.
Local tests show a 4x speedup when copying from 1-element JSArrays.
As the source array becomes larger, the time spent copying elements
begins to dominate.
Bug: v8:3590
Change-Id: I05ebe54d7b255d0a76ad46ac11ce7cfd516b8ac8
Reviewed-on: https://chromium-review.googlesource.com/789010
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49634}
This fixes the computation of the {may_have_interesting_symbols} flag
for the last map computed in {Map::AddMissingTransitions} method. The
last map is allocated ahead of time, but the flag is only correct once
the descriptors are actually installed in the end.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-786020
BUG=chromium:786020
Change-Id: Iff97780609fe596437eb6bea85606a1c3bb2ac4c
Reviewed-on: https://chromium-review.googlesource.com/789839
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49631}
Previously, the class fields initializer function was stored on a
synthetic context allocated variable. This approach had sevaral
problems:
- We didn't know that class literal had fields until after we had
completely parsed the class literal. This meant that we had to go back
and fix up the scope of the constructor to have this synthetic
variable. This resulted in mismatch between parser and preparsed scope
data.
- This synthetic variable could potentially resolve to an initializer
of an outer class.
For ex:
class X extends Object {
c = 1;
constructor() {
var t = () => {
class P extends Object {
constructor() {
var t = () => { super(); };
t();
}
}
super();
}
t();
}
}
In this the inner class P could access the outer class X's initiliazer
function. We would have to maintain extra metadata to make sure this
doesn't happen.
Instead this new approach uses a private symbol to store the
initializer function on the class constructor itself.
For the base constructor case, we can simply check for a bit on the
constructor function literal to see if we need to emit code that loads
and calls this initializer function. Therefore, we don't pay the cost
of loading this function in case there are no class fields.
For the derived constructor case, there are two possiblities:
(a) We are in a super() call directly in the derived constructor:
In this case we can do a check similar to the base constructor check,
we can check for a bit on the derived constructor and emit code for
loading and calling the initializer function.
This is usually the common case and we don't pay any cost for not using
class fields.
(b) We are in a super() call inside an arrow function in the derived
constructor:
In this case, we /always/ emit code to load and call the initializer
function. If the function doesn't exist then we have undefined and we
don't call anything. Otherwise we call the function.
super() can't be called twice so even if we emit code to load and call
the initializer function multiple times, it doesn't matter because it
would have already been an error.
Bug: v8:5367
Change-Id: I7f77cd6493ff84cf0e430a8c1039bc9ac6941a88
Reviewed-on: https://chromium-review.googlesource.com/781660
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49628}
This is a reland of 4d3bc552b5
Original change's description:
> [coverage] add coverage for binary expressions
>
> Adds block-level coverage tracking for binary && and ||
> expressions. Introduces a BinaryOperation source-range
> for tracking the operations themselves and an Expression
> source-range, used for tracking NaryLogical expressions.
>
> This builds on work by jgruber@chromium.org in
> the issue.
>
> TBR=marja@chromium.org
> R=jgruber@chromium.org, rmcilroy@chromium.org
>
> Bug: v8:6660
> Change-Id: I83a81f13a3514a734c06948b2d3e91138fb00e18
> Reviewed-on: https://chromium-review.googlesource.com/754564
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49304}
Bug: v8:6660
Change-Id: I1c8571660d6c501d526886867bd841c49d5c44fd
Reviewed-on: https://chromium-review.googlesource.com/778288
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49613}
The existing access to the signatures is plain wrong. This CL fixes
this.
Note that cross-instance indirect calls are only enabled since a few
days (https://crrev.com/c/778159), which is why this bug was not
detected before.
R=titzer@chromium.org
Bug: chromium:787910
Change-Id: Iaac4d1d85840c921eb8554c5094933ec8d987802
Reviewed-on: https://chromium-review.googlesource.com/787312
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49607}
The typer's ToNumber (and thus ToInteger etc.) returns type None when
the input type is BigInt, but we weren't quite ready for that in a few
places.
R=jarin@chromium.org
Bug: v8:7121
Change-Id: Ib12c726338f1ec3dfb9ba5cf54b00cc8d1351a89
Reviewed-on: https://chromium-review.googlesource.com/785130
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49604}
The tsan skips were getting a bit spread all over the place. Added a
section for them below msan and asan to keep things together, where
the only cause for skipping the test is tsan.
Bug: v8:7093
Change-Id: I606c3ab2f23e4159c12c1e81d28e855412158f15
Reviewed-on: https://chromium-review.googlesource.com/785810
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49599}
The main reason why we currently don't see this fail is that block-scopes always appear to have an extension: the scope info object is stored there.
Bug:
Change-Id: I38f0c15387e235eeea9a57c95af0d9eb185dad2a
Reviewed-on: https://chromium-review.googlesource.com/785951
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49585}
This test used to run 10M loop iterations to trigger OSR. Let's run 5
instead and trigger OSR manually through the runtime.
Bug: v8:7093
Change-Id: Ie0cdb9389ca465bf433e81a17fa60c300edc3e29
Reviewed-on: https://chromium-review.googlesource.com/785693
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49579}
The test is flaky due to huge string allocation.
Bug: v8:7093
Change-Id: I2f17eb8b96b569d84a1f5c9549753fd0ab7fee89
Reviewed-on: https://chromium-review.googlesource.com/785351
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49575}
These tests can take up to 10 minutes on bots. Split them up to
increase parallelism.
Bug: v8:7093
Change-Id: Iabfd34a7f2476d4add51da807f2e987e8d1153c9
Reviewed-on: https://chromium-review.googlesource.com/785411
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49573}
This is a reland of 712fa67554.
Original change's description:
> [test] Add Liftoff variant
>
> Add a variant for testing the current state of the Liftoff
> implementation.
> This variant will only run on a subset of the bots, just like the
> --future variant.
>
> R=machenbach@chromium.org, hablich@chromium.org
>
> Bug: v8:7088, v8:6600
> Change-Id: If49fad3a8ed579356504b821a787326754f24e78
> Reviewed-on: https://chromium-review.googlesource.com/779420
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49504}
TBR=machenbach@chromium.orgCC=hablich@chromium.org
Bug: v8:7088, v8:6600
Change-Id: Ieb20020f07c70acaa64bb421763a41aa163a261b
Reviewed-on: https://chromium-review.googlesource.com/781499
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49531}
The integer value denoting the number of captures (and thus the size
of the list of captures created in @@replace [0]) can be controlled by
the user. This CL ensures we don't overflow and respect
Code::kMaxArguments, but note that it is still possible to trigger
OOMs through large lists.
Bug: chromium:786573
Change-Id: I19c88908c594487818d083b2ba423764ef91eae0
Reviewed-on: https://chromium-review.googlesource.com/779001
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49530}
This is a reland of 236298acbf.
Original change's description:
> [wasm] Unify deoptimization data
>
> Add methods to add deoptimization data and use them from all the places
> where we currently add them manually. Also add them to wasm-to-wasm
> wrappers compiled on table set, which was missing before, leading to
> the referenced bug.
>
> R=ahaas@chromium.org
>
> Bug: chromium:779292
> Change-Id: Ib9132d9faeb1092c46e22dd8196d201ce5c0942f
> Reviewed-on: https://chromium-review.googlesource.com/774838
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49452}
Bug: chromium:779292
Change-Id: I8219305fc894c50904db57e51245733f6613dcd3
Reviewed-on: https://chromium-review.googlesource.com/778159
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49508}
When collecting source ranges for conditionals (`a ? b : c`), include
the '?' and ':' tokens in the then- and else ranges, respectively.
Bug: v8:7098
Change-Id: I22315e2040c96c977e0b49e1fafe4228a6558471
Reviewed-on: https://chromium-review.googlesource.com/778321
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49484}
This CL also includes fixes for CF issues found while the previous
reland was active.
Bug: v8:5799, chromium:783902, chromium:783926, chromium:783822
Change-Id: I1f7d9b037d90838469c45f5d72771a77444c662e
Reviewed-on: https://chromium-review.googlesource.com/764067
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49457}
This reverts commit 236298acbf.
Reason for revert: suspected cause of failures on GC stress bots:
https://build.chromium.org/p/client.v8/builders/V8%20Mac%20GC%20Stress/builds/16341https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/16269
Original change's description:
> [wasm] Unify deoptimization data
>
> Add methods to add deoptimization data and use them from all the places
> where we currently add them manually. Also add them to wasm-to-wasm
> wrappers compiled on table set, which was missing before, leading to
> the referenced bug.
>
> Drive-by: Disable non-applicable MaybeHandle constructors to allow
> overloading functions with different Handle types.
>
> R=ahaas@chromium.org
>
> Bug: chromium:779292
> Change-Id: Ib9132d9faeb1092c46e22dd8196d201ce5c0942f
> Reviewed-on: https://chromium-review.googlesource.com/774838
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49452}
TBR=ahaas@chromium.org,clemensh@chromium.org
Change-Id: I02fb49d2ece8e04ac5fb26f618bfe6fb2f133d06
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:779292
Reviewed-on: https://chromium-review.googlesource.com/777079
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49455}
This reverts commit 4d3bc552b5.
Reason for revert: https://crbug.com/785778
Original change's description:
> [coverage] add coverage for binary expressions
>
> Adds block-level coverage tracking for binary && and ||
> expressions. Introduces a BinaryOperation source-range
> for tracking the operations themselves and an Expression
> source-range, used for tracking NaryLogical expressions.
>
> This builds on work by jgruber@chromium.org in
> the issue.
>
> TBR=marja@chromium.org
> R=jgruber@chromium.org, rmcilroy@chromium.org
>
> Bug: v8:6660
> Change-Id: I83a81f13a3514a734c06948b2d3e91138fb00e18
> Reviewed-on: https://chromium-review.googlesource.com/754564
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49304}
TBR=rmcilroy@chromium.org,marja@chromium.org,jgruber@chromium.org,ben@npmjs.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:6660
Change-Id: Ie017c528604b2e01400f527511413eaea5786198
Reviewed-on: https://chromium-review.googlesource.com/776768
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49454}
Both of these features were shipped in Chrome 62.
Bug: v8:4545, v8:6172
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Ie00dcbeded7517a15696d4a78fcfbbf162919923
Reviewed-on: https://chromium-review.googlesource.com/775601
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49453}
Add methods to add deoptimization data and use them from all the places
where we currently add them manually. Also add them to wasm-to-wasm
wrappers compiled on table set, which was missing before, leading to
the referenced bug.
Drive-by: Disable non-applicable MaybeHandle constructors to allow
overloading functions with different Handle types.
R=ahaas@chromium.org
Bug: chromium:779292
Change-Id: Ib9132d9faeb1092c46e22dd8196d201ce5c0942f
Reviewed-on: https://chromium-review.googlesource.com/774838
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49452}
This test uses 136GB of memory which is too much for our MIPS boards.
NOTRY=true
Bug: v8:7093
Change-Id: I382bf0832da6ae74241e89a2016c3738f03979fd
Reviewed-on: https://chromium-review.googlesource.com/776765
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49443}
It was shipped in Chrome 62.
Bug: v8:5070
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I77119540411d1fe15691d40012cb96f4e2e45048
Reviewed-on: https://chromium-review.googlesource.com/776154
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49434}
"AbsoluteDivSmall" had a shortcut path for abs(divisor) == 1 where
it would simply return the dividend as result. However, its caller
"Divide" was blissfully ignorant of this trick and would therefore
simply set the value's sign as needed, modifying the input.
This CL prevents that, while continuing to avoid the full division
algorithm for abs(divisor) == 1.
Bug: v8:6791
Change-Id: I04cdc93f5ed2a696587c35c754e68f07012dd1a9
Reviewed-on: https://chromium-review.googlesource.com/772332
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49433}
Reland of https://chromium-review.googlesource.com/c/v8/v8/+/727893
The crashes should be fixed by https://chromium-review.googlesource.com/c/v8/v8/+/763531
Original change's description:
> Revert "Reland^5 "[turbofan] eagerly prune None types and deadness from the graph""
>
> This reverts commit ac0661b358.
>
> Reason for revert: Clusterfuzz unhappy: chromium:783019 chromium:783035
>
> Original change's description:
> > Reland^5 "[turbofan] eagerly prune None types and deadness from the graph"
> >
> > This gives up on earlier attempts to interpret DeadValue as a signal of
> > unreachable code. This does not work because free-floating dead value
> > nodes, and even pure branch nodes that use them, can get scheduled so
> > early that they get reachable. Instead, we now eagerly remove branches
> > that use DeadValue in DeadCodeElimination and replace DeadValue inputs
> > to value phi nodes with dummy values.
> >
> > Reland of https://chromium-review.googlesource.com/715716
> >
> > Bug: chromium:741225 chromium:776256
> > Change-Id: I251efd507c967d4a8882ad8fd2fd96c4185781fe
> > Reviewed-on: https://chromium-review.googlesource.com/727893
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#49188}
>
> TBR=jarin@chromium.org,tebbi@chromium.org
>
> Bug: chromium:741225 chromium:776256 chromium:783019 chromium:783035
> Change-Id: I6a8fa3a08ce2824a858ae01817688e63ed1f442e
> Reviewed-on: https://chromium-review.googlesource.com/758770
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49262}
TBR=jarin@chromium.org,tebbi@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:741225 chromium:776256 chromium:783019 chromium:783035
Change-Id: I6c02b4beb02997ec34015ed2f6791a93c70f5e36
Reviewed-on: https://chromium-review.googlesource.com/772150
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49429}
This is a reland of 77b0baa649.
Original change's description:
> [wasm] Fix importing wasm-lazy-compile stubs
>
> If two modules use lazy compilation, and one imports a function of
> another, we are unwrapping the js-to-wasm wrapper of the export. This
> was failing so far, because during unwrapping we did not find the wasm
> code.
> This CL fixes this by also recognizing WasmCompileLazy stubs as "wasm
> code".
>
> R=ahaas@chromium.org
>
> Bug: chromium:779569, v8:5991
> Change-Id: If2260c3721e3746a7635b9d0182fd520df2fb773
> Reviewed-on: https://chromium-review.googlesource.com/771672
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49405}
Bug: chromium:779569, v8:5991
Change-Id: I4818e933467bd5a040f1514b8fc18db219a092c7
Reviewed-on: https://chromium-review.googlesource.com/774538
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49426}
When initializing the stack state at a merge point, don't force all
stack slots into registers. Allow constants to stay constants as long
as they are not part of the merge. Otherwise we might break assumptions
of outer blocks which then try to merge a register into a constant and
fail.
Also, add some documentation to {InitMergeStackSlot} to document the
intent of the implementation.
R=titzer@chromium.org
Bug: v8:784050, v8:6600
Change-Id: I3a4c83b446909027be075d3207cb7c748a6b1aad
Reviewed-on: https://chromium-review.googlesource.com/766353
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49423}
This reverts commit 77b0baa649.
Reason for revert: Breaks on win64 bot: https://logs.chromium.org/v/?s=chromium%2Fbb%2Fclient.v8%2FV8_Win64_-_debug%2F20172%2F%2B%2Frecipes%2Fsteps%2FCheck%2F0%2Flogs%2Flazy-compilation%2F0
Original change's description:
> [wasm] Fix importing wasm-lazy-compile stubs
>
> If two modules use lazy compilation, and one imports a function of
> another, we are unwrapping the js-to-wasm wrapper of the export. This
> was failing so far, because during unwrapping we did not find the wasm
> code.
> This CL fixes this by also recognizing WasmCompileLazy stubs as "wasm
> code".
>
> R=ahaas@chromium.org
>
> Bug: chromium:779569, v8:5991
> Change-Id: If2260c3721e3746a7635b9d0182fd520df2fb773
> Reviewed-on: https://chromium-review.googlesource.com/771672
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49405}
TBR=ahaas@chromium.org,clemensh@chromium.org
Change-Id: If5ab7b9de95ef662a65a6a5b919fa1f13aa492cd
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:779569, v8:5991
Reviewed-on: https://chromium-review.googlesource.com/774518
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49409}
Previously, we had lazy parsing of class constructor disabled when a
class literal had class fields because we were using a reference to
the initializer function variable to load the function and call it.
Instead, in this patch, we use the scope analysis to lookup this
initializer function variable.
Bug: v8:5367
Change-Id: Ib73d7e6abed33c04d1f574e7976bea4869d54757
Reviewed-on: https://chromium-review.googlesource.com/768384
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49406}
If two modules use lazy compilation, and one imports a function of
another, we are unwrapping the js-to-wasm wrapper of the export. This
was failing so far, because during unwrapping we did not find the wasm
code.
This CL fixes this by also recognizing WasmCompileLazy stubs as "wasm
code".
R=ahaas@chromium.org
Bug: chromium:779569, v8:5991
Change-Id: If2260c3721e3746a7635b9d0182fd520df2fb773
Reviewed-on: https://chromium-review.googlesource.com/771672
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49405}
When calling the CWasmEntry in order to call from the interpreter to a
wasm function, the given buffer must hold the arguments, and must also
have enough space to hold the return values. We were missing the second
part, hence we failed when there are no parameters, but a return.
R=ahaas@chromium.org
Bug: chromium:784125
Change-Id: I08d417cae60eea64fda8a72e898dbed9f3e88148
Reviewed-on: https://chromium-review.googlesource.com/771633
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49402}
We need to explicitly rule out negative indices for the out-of-bounds
case, otherwise we can end up with a monomorphic KeyedLoadIC that allows
OOB accesses, but doesn't properly check whether there are properties
with negative integer names on the receiver.
Bug: chromium:784835
Change-Id: Ic3ef5438b76094f024de0c6348183fb62b32088c
Reviewed-on: https://chromium-review.googlesource.com/774278
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49396}
The backing store fixed array for collections needs to be allocated
in LOS if it exceeds the maximum regular heap object size.
Drive-by-fix: Only store fixed array map once as per TODO.
Bug: chromium:784862
Change-Id: I6b4dd2e45153ae107171e21bc7448e0d9b54b0ed
Reviewed-on: https://chromium-review.googlesource.com/771150
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49378}
Adds a stress-background-compile mode which runs compilation on a background
thread at the same time as compiling on the main thread to flush out races.
This is added as one of the variants, removing stress_asm_validation since this
is no longer a useful variant.
BUG=v8:5203
Change-Id: I73dd9f21d9b6da4a4cb39c05061aa24116e6c5ad
Reviewed-on: https://chromium-review.googlesource.com/741746
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49376}
Previously, the Parser stored a Scope alongside a RewritableExpression
for each potential destructuring assignment. This Scope was later used
during rewriting to set the correct context for the rewriting. But this
approach failed if a new Scope was inserted into the Scope chain between
the time the assignment was parsed and when it was rewritten.
By storing the Scope directly in RewritableExpression,
ReparentExpressionScopes() is able to appropriately re-scope such
expressions prior to their rewriting.
Bug: chromium:779457
Change-Id: Ieb429a3da841f76d5798610af59da4fccb000652
Reviewed-on: https://chromium-review.googlesource.com/767666
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49368}
Make sure we have at least two elements in the Map, otherwise we don't
perform a proper dictionary lookup.
Bug: chromium:781218
Change-Id: I471e3822b95c15e3a5b2ac54c8ad1f030bd54d40
Reviewed-on: https://chromium-review.googlesource.com/768708
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49345}
- Remove weak-collection.js
- Adds TFJ builtins for WeakSet and WeakMap constructors
- Unified helpers and constructor behavior into a BaseCollectionsAssembler
- Fast paths for...
- unmodified constructor function
- argument is a fast JS array
- entries are fast JS arrays, for Map/WeakMap
- no arguments passed
Quick benchmarks shows significant improvements (1.12x - 5.7x!) for ALL collection constructors (weak and non-weak):
https://github.com/peterwmwong/v8-perf/blob/master/weakcollection-constructor/README.md
More could be done for performance. Currently we always call out to JS to add entries, if we knew the prototype was unmodified, we could call the builtins directly.
Bug: v8:5049, v8:6604
Change-Id: Id7912c1eed5bcf512df7fd6238f04166a8a5937e
Reviewed-on: https://chromium-review.googlesource.com/760385
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49343}
Fix two more places where StringToBigInt differs from parseInt:
- Binary and octal radix prefixes are supported
- Trailing non-whitespace junk is not allowed
This is done with a new Behavior enum in BigIntParseIntHelper,
along with a couple of bool configuration flags in StringToIntHelper.
Bug: v8:6791, v8:7038
Change-Id: Ib91bfc5ccb04ad0dd6c99bc81e19c1239264a469
Reviewed-on: https://chromium-review.googlesource.com/764595
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49335}
This fixes a corner-case where resuming a suspended generator would not
perform stack overflow checks and hence cause the stack to grow without
bounds.
R=neis@chromium.org
BUG=chromium:781583
Change-Id: Ib04116e489ac6b962cb821263860497abb57bbae
Reviewed-on: https://chromium-review.googlesource.com/765953
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49327}
The only empty PropertyArray is the empty_property_array object on the
isolate. Allowing empty PropertyArrays causes the turbofan to ignore the
existing hash when growing the backing store again. We currently only end
up with the empty PropertyArray when following back transitions.
Bug: chromium:781218, chromium:783713
Change-Id: If41dd09b965cdc8d957b9ca50ba3c8a7f4254769
Reviewed-on: https://chromium-review.googlesource.com/763230
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49318}
Adds block-level coverage tracking for binary && and ||
expressions. Introduces a BinaryOperation source-range
for tracking the operations themselves and an Expression
source-range, used for tracking NaryLogical expressions.
This builds on work by jgruber@chromium.org in
the issue.
TBR=marja@chromium.orgR=jgruber@chromium.org, rmcilroy@chromium.org
Bug: v8:6660
Change-Id: I83a81f13a3514a734c06948b2d3e91138fb00e18
Reviewed-on: https://chromium-review.googlesource.com/754564
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49304}
This is a reland of 6c6132880a
Original change's description:
> [Liftoff] Implement parallel register moves
>
> This was not implemented so far, leading to lots of clusterfuzz issues.
> Testing this feature would require complicating the interface a lot and
> exposing more implementation details in the header file, hence we just
> go with regression tests for now.
>
> R=ahaas@chromium.org, titzer@chromium.org
>
> Bug: v8:6600, chromium:782280
> Change-Id: I12863f3eb59a8dffdcc7d3bfb8e1f0ae0eec15ee
> Reviewed-on: https://chromium-review.googlesource.com/758772
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49286}
Bug: v8:6600, chromium:782280
Change-Id: I82a75bfeaf83dc63a2917da3ccdc4721c5d689e7
Reviewed-on: https://chromium-review.googlesource.com/763387
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49292}
This reverts commit 6c6132880a.
Reason for revert: breaks compilation on win64 bot: https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20msvc/builds/69
Original change's description:
> [Liftoff] Implement parallel register moves
>
> This was not implemented so far, leading to lots of clusterfuzz issues.
> Testing this feature would require complicating the interface a lot and
> exposing more implementation details in the header file, hence we just
> go with regression tests for now.
>
> R=ahaas@chromium.org, titzer@chromium.org
>
> Bug: v8:6600, chromium:782280
> Change-Id: I12863f3eb59a8dffdcc7d3bfb8e1f0ae0eec15ee
> Reviewed-on: https://chromium-review.googlesource.com/758772
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49286}
TBR=titzer@chromium.org,ahaas@chromium.org,clemensh@chromium.org
Change-Id: I386983da7f9f03d54cef2190b01fd2cc5785966e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6600, chromium:782280
Reviewed-on: https://chromium-review.googlesource.com/763367
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49289}
This was not implemented so far, leading to lots of clusterfuzz issues.
Testing this feature would require complicating the interface a lot and
exposing more implementation details in the header file, hence we just
go with regression tests for now.
R=ahaas@chromium.org, titzer@chromium.org
Bug: v8:6600, chromium:782280
Change-Id: I12863f3eb59a8dffdcc7d3bfb8e1f0ae0eec15ee
Reviewed-on: https://chromium-review.googlesource.com/758772
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49286}
There were some places left where that could happen.
Bug: chromium:782754
Change-Id: I1db1f5b361cdf443b730a220c0e569ad48dd298d
Reviewed-on: https://chromium-review.googlesource.com/758841
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49283}
I made a mistake in yesterday's cleanup.
R=jarin@chromium.org
Bug: chromium:783051
Change-Id: Iabd7403096197ce8e54d46e079bc9a70aa98578d
Reviewed-on: https://chromium-review.googlesource.com/758765
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49266}
Since the deoptimizer generalizes maps for all materialized objects, it
must make sure that none of the object's fields contain mutable heap numbers
(only double fields are allowed to point to mutable heap numbers). With this CL,
we simply change any mutable heap numbers in property arrays to immutable ones.
This could be dangerous if some non-materialized object could point to this
property array, but this cannot happen because interpreter registers cannot
refer to naked property arrays.
Bug: chromium:776309
Change-Id: I897b604fa804de673710cfa3ba0595dbd9f80eeb
Reviewed-on: https://chromium-review.googlesource.com/759781
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49263}
This reverts commit ac0661b358.
Reason for revert: Clusterfuzz unhappy: chromium:783019 chromium:783035
Original change's description:
> Reland^5 "[turbofan] eagerly prune None types and deadness from the graph"
>
> This gives up on earlier attempts to interpret DeadValue as a signal of
> unreachable code. This does not work because free-floating dead value
> nodes, and even pure branch nodes that use them, can get scheduled so
> early that they get reachable. Instead, we now eagerly remove branches
> that use DeadValue in DeadCodeElimination and replace DeadValue inputs
> to value phi nodes with dummy values.
>
> Reland of https://chromium-review.googlesource.com/715716
>
> Bug: chromium:741225 chromium:776256
> Change-Id: I251efd507c967d4a8882ad8fd2fd96c4185781fe
> Reviewed-on: https://chromium-review.googlesource.com/727893
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49188}
TBR=jarin@chromium.org,tebbi@chromium.org
Bug: chromium:741225 chromium:776256 chromium:783019 chromium:783035
Change-Id: I6a8fa3a08ce2824a858ae01817688e63ed1f442e
Reviewed-on: https://chromium-review.googlesource.com/758770
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49262}
R=yangguo@chromium.org
This is a reland of
for the no-i18n configuration.
https: //chromium-review.googlesource.com/c/v8/v8/+/571746 with a fix
Bug:
Change-Id: I3e654791267b20fb3703ad4220404d8078f43440
Reviewed-on: https://chromium-review.googlesource.com/758999
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Erik Corry <erikcorry@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49251}
This patch adds support for Regional_Indicator within Unicode property
escapes in regular expressions.
The Regional_Indicator binary property was added in Unicode v10 and is
supported in ICU 60.1.
An `#if` directive is used to prevent breaking Node.js until they
update their ICU.
BUG=v8:4743
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I7acec13c8ae7552558a0f852937984bba828e738
Reviewed-on: https://chromium-review.googlesource.com/758273
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49250}
Like CSP flag 'unsafe-eval', which communicates if both JS source
files and WASM binary files may be compiled, this CL adds a similar
flag for the compilation of WASM binary files.
That is, a WASM binary file will be compiled only if the new flag is
defined, or the flag for 'unsafe-eval' allows it. These flags are
implemented as callback functions on the isolate. The callbacks get a
(CSP) context, and a string, and returns the corresponding value of
the flag.
Both callbacks are initialized with the nullptr, and is used to
communicate that no CSP policy is defined. This allows this concept to
work, independent of it running in Chrome.
It also does a small clean up in api.cc to use macro CALLER_SETTERS,
instead of explicit code when appropriate.
Bug: v8:7041
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Idb3356574ae2a298057e6b7bccbd3492831952ae
Reviewed-on: https://chromium-review.googlesource.com/759162
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Eric Holk <eholk@chromium.org>
Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49243}
StoreDataPropertyInLiteral doesn't throw (because the previous uses of
this didn't throw), but class fields can throw on defining the
property which means we can't use this. Changing to CreateDataProperty
runtime call instead.
Bug: v8:5367
Change-Id: I1ab45413b121972dd18fe2b35a0cedd8efe0e0bf
Reviewed-on: https://chromium-review.googlesource.com/757824
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49239}
This patch adds support for Emoji_Component within Unicode property
escapes in regular expressions.
The Emoji_Component binary property was added in Emoji data v5
and is supported in ICU 60.1.
An `#if` directive is used to prevent breaking Node.js until they
update their ICU.
BUG=v8:4743
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: If1b49a4c175e88f1840ca5ef8d57829d6d8c3291
Reviewed-on: https://chromium-review.googlesource.com/758261
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49229}
The C_WASM_ENTRY only calls wasm code, so (outgoing) parameters of this
code are always untagged.
R=ahaas@chromium.org
Bug: v8:7049
Change-Id: I989908eea668bd56aa88f3f1744105d218584ef1
Reviewed-on: https://chromium-review.googlesource.com/758245
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49221}
The regexp fast path in MaybeCallFunctionAtSymbol had an issue in which
we'd call ToString after checking that the given {object} was a fast
regexp and deciding to take the fast path. This is invalid since
ToString() can call into user-controlled JS and may mutate {object}.
There's no way to place the ToString call correctly in this instance:
1 before BranchIfFastRegExp, it's a spec violation if we end up on the
slow regexp path;
2 the problem with the current location is already described above;
3 and we can't place it into the fast-path regexp builtin (e.g.
RegExpReplace) either due to the same reasons as 1.
The solution in this CL is to restrict the fast path to string
arguments only, i.e. cases where ToString would be a nop and can safely
be skipped.
Bug: chromium:782145
Change-Id: Ifd35b3a9a6cf2e77c96cb860a8ec98eaec35aa85
Reviewed-on: https://chromium-review.googlesource.com/758257
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49213}
Creates a new initializer function to instantiate instance class
fields in a base class.
An initializer function (similar to the one created for static fields)
is created during class declaration and assigned to a synthetic
context allocated variable.
This function is loaded from the variable during instantiation (when
the constructor is run) and run.
Bug: v8:5367
Change-Id: Ie11c2183b3001234ae41d7bcc2cb9b02c0764ab5
Reviewed-on: https://chromium-review.googlesource.com/754445
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49207}
This gives up on earlier attempts to interpret DeadValue as a signal of
unreachable code. This does not work because free-floating dead value
nodes, and even pure branch nodes that use them, can get scheduled so
early that they get reachable. Instead, we now eagerly remove branches
that use DeadValue in DeadCodeElimination and replace DeadValue inputs
to value phi nodes with dummy values.
Reland of https://chromium-review.googlesource.com/715716
Bug: chromium:741225 chromium:776256
Change-Id: I251efd507c967d4a8882ad8fd2fd96c4185781fe
Reviewed-on: https://chromium-review.googlesource.com/727893
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49188}
The bytecode generator has special handling for comparing the result of
the typeof operator against a string literal. This needs to be adapted
for bigints.
R=jkummerow@chromium.org, mythrie@chromium.org
Bug: v8:6791
Change-Id: I42d6c9e9225ce05e19393f10e01ae496ecb70c9c
Reviewed-on: https://chromium-review.googlesource.com/753465
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49172}
Actually all it does is throw a TypeError.
R=jkummerow@chromium.org
Bug: v8:6791
Change-Id: I884da4eaa937519c07c3516a1713829f52e28ad8
Reviewed-on: https://chromium-review.googlesource.com/753730
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49171}
This test uses a lot of memory and is causing OOM crashes on bots.
Bug: v8:7042
Change-Id: I63ff4d44ca8e26b65875df53ebd235976183c558
Reviewed-on: https://chromium-review.googlesource.com/755593
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49161}
When initializing the cache state for a merge, we should never use
registers multiple times. Other code paths leading to the same merge
point might provide different values for the different slots there.
R=ahaas@chromium.org
Bug: v8:7035, v8:6600
Change-Id: I8e409b494af0fdc1a5045ec04571611b97fcaf86
Reviewed-on: https://chromium-review.googlesource.com/754816
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49150}
The maximum length of the chars in bytes was hardcoded and was not
updated with the increase in string length on 64-bit platforms.
The other platforms don't do this debug check so they don't need
updating.
Bug: chromium:779407
Change-Id: I94fd946f9e67b39075c1f7eed14a20e9db126a72
Reviewed-on: https://chromium-review.googlesource.com/753584
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49142}
If the destination register of a binop is the same register as the
right hand side, we would first move the left hand side into that
register (overwriting the value of the rhs), and then use the rhs.
This CL fixes this issue and adds a regression test.
R=ahaas@chromium.org
Bug: v8:6600, v8:7033
Change-Id: Ief90b5bcffc65823037bc57fb00741b2448e6375
Reviewed-on: https://chromium-review.googlesource.com/753462
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49137}
We must throw a SyntaxError only when failing to convert a string. In
the other cases we must throw a TypeError.
R=jkummerow@chromium.org
Bug: v8:6791
Change-Id: I802d8b6830b341f87e46e7de198af74ba95b8658
Reviewed-on: https://chromium-review.googlesource.com/752803
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49131}
This reverts commit e83ee94565.
Reason for revert: Check failure in regress-v8-6940.js
Original change's description:
> RegExp: Add the ability to switch flags on and off within the regexp.
>
> This is a reland of https://chromium-review.googlesource.com/c/v8/v8/+/752522
> which was itself a reupload of
> https://chromium-review.googlesource.com/c/v8/v8/+/571746 where reviews took
> place.
>
> R=yangguo@chromium.org
>
> Bug:
> Change-Id: Ia4dbdd6e9a362e272753ff10dc66b7f72d81ee20
> Reviewed-on: https://chromium-review.googlesource.com/753596
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Erik Corry <erikcorry@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49129}
TBR=yangguo@chromium.org,erikcorry@chromium.org
Change-Id: I5ee94c47606101d06010c9e6b4b78ca51566b60a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/754682
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49130}
The condition for bounds check generation was not in sync with the
condition that was used for the actual access, which lead to invalid
memory accesses when the array protector was invalid.
Tbr: tebbi@chromium.org
Bug: chromium:781506, chromium:781494, chromium:781457, chromium:781285, chromium:781381, chromium:781380, v8:6936, v8:7014, v8:7027
Change-Id: Ia5b2ad02940292572ed9b37abd3f9ffaa6d7a26b
Reviewed-on: https://chromium-review.googlesource.com/753590
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49124}
This patch evaluates computed properties in the order of declaration
during class definition time.
This patch creates a synthetic variable to store the result of
evaluating a computed property and then looks this up in the
initializer function.
Bug: v8:5367
Change-Id: I4182c6a01196d2538991818142890f6afb0e532b
Reviewed-on: https://chromium-review.googlesource.com/752567
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49115}
We don't use ICs for the Array.prototype and the Object.prototype
because the runtime has to be able to intercept them properly (for the
global protectors). So we better make sure that TurboFan doesn't
outsmart the system by storing to elements of either prototype directly.
Bug: chromium:781116
Change-Id: I0f521601ef02c1b21018abd1bf1028fd8a811e84
Reviewed-on: https://chromium-review.googlesource.com/753089
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49101}
This reverts commit 68212c80c3.
Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20noi18n%20-%20debug/builds/17200
Original change's description:
> RegExp: Add the ability to switch flags on and off within the regexp
>
> R=yangguo@chromium.org
>
> This is a reupload of https://chromium-review.googlesource.com/c/v8/v8/+/571746
> with a different user, since the other one was not allowed to commit to V8 any
> more.
>
> Bug:
> Change-Id: I6171afd44e514f6c934390faab6f9bee3953ac77
> Reviewed-on: https://chromium-review.googlesource.com/752522
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49098}
TBR=erik.corry@gmail.com,yangguo@chromium.org,erikcorry@chromium.org,jgruber@chromium.org
Change-Id: I651c5618f09f43104af50cb1319ab7b49011573e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/752802
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49099}
This turns on the existing --internalize_on_the_fly flag for the
MEGAMORPHIC KeyedLoadIC to properly internalize strings before
looking up the property. This avoids the otherwise taken runtime
call to %KeyedGetProperty, which is definitely slower.
Initially the --internalize_on_the_fly flag was turned off because
internalizing strings on the fly causes too much traffic on the
megamorphic stub cache. We avoid this problem here by not probing
the stub cache in that case, which still gives the benefit of not
having to go to the runtime.
This improves the babylon test on the web-tooling-benchmark by around
2-3% and will probably also help with several tests (like React or
Ember) on the Speedometer benchmark.
If this CL causes trouble (i.e. tanks something important), we can
just turn off the --internalize_on_the_fly flag again.
Bug: v8:6936, v8:7026
Change-Id: If295ed3fd013f8b0ff031f9979e7df21dab817b6
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/751464
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49093}
- Add WeakMapPrototypeDelete and WeakSetPrototypeDelete TFJ builtins
- Fast paths when it's not necessary to shrink the table
- Add WeakCollectionDelete TFS
Some quick benchmarks shows 1.4x - 2.15x gains in performance.
https://github.com/peterwmwong/v8-perf/blob/master/weakcollection-delete/README.md
Bug: v8:5049, v8:6604
Change-Id: I14036df153f3a0242f9083d751658b868b16660a
Reviewed-on: https://chromium-review.googlesource.com/743864
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49076}
The existing stack check only checked the number of stack frames on the
stack, not the actual size of the stack frames. In the test case, each
stack frame is huge, and the interpreter runs out of memory before the
stack check stops the execution. With this change we take the size of
the value stack and the size of the control stack and compare their sum
to the stack limit of V8. Note that this stack limit is kind of
arbitrary, because the stack space of the interpreter is not on the
actual runtime stack but allocated in zone memory, and the stack check
exists to simulate stack overflows in compiled code, not to prevent
actual stack overflows.
R=clemensh@chromium.org
TEST=mjsunit/regress/wasm/regress-778917
Bug: chromium:778917
Change-Id: Ife47631fcb1a178a68facab1e42c0069b12c0155
Reviewed-on: https://chromium-review.googlesource.com/744003
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49071}
Proxy's call trap can be used to cause recursion.
R=bmeurer@chromium.org, tebbi@chromium.org
Bug: chromium:779344
Change-Id: I19c989f618f7230028ebe18c3415bc3f4bd72b93
Reviewed-on: https://chromium-review.googlesource.com/743782
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49069}
This CL adds support for two byte string comparisons to the StringEqual
builtin, which so far was bailing out to the generic %StringEqual
runtime function whenever any two-byte string was involved. This made
comparisons that involved two-byte strings, either comparing them to
one-byte strings or comparing two two-byte strings, up to 3x slower than
if only one-byte strings were involved.
With this change, all direct string (SeqString or ExternalString)
equality checks are roughly on par now, and the weird performance cliff
is gone. On the micro-benchmark from the bug we go from
stringEqualBothOneByteSeqString: 162 ms.
stringEqualTwoByteAndOneByteSeqString: 446 ms.
stringEqualOneByteAndTwoByteSeqString: 438 ms.
stringEqualBothTwoByteSeqString: 472 ms.
to
stringEqualBothOneByteSeqString: 151 ms.
stringEqualTwoByteAndOneByteSeqString: 158 ms.
stringEqualOneByteAndTwoByteSeqString: 166 ms.
stringEqualBothTwoByteSeqString: 160 ms.
which is the desired result. On the esprima test of the
web-tooling-benchmark we seem to improve by 1-2%, which corresponds to
the savings of going to the runtime for many StringEqual comparisons.
Drive-by-cleanup: Introduce LoadAndUntagStringLength helper into the CSA
with proper typing to avoid the unnecessary shifts on 64-bit platforms
when keeping the length tagged initially in StringEqual.
Bug: v8:4913, v8:6365, v8:6371, v8:6936, v8:7022
Change-Id: I566f4b80e217513775ffbd35e0480154abf59b27
Reviewed-on: https://chromium-review.googlesource.com/749223
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49067}
The parser now throws for literals that are too big for the runtime
to support, thus avoiding CHECK-failures further down the line.
Tbr: rmcilroy@chromium.org
Bug: v8:6791
Change-Id: Ie45ddebb8aa9e7a30e8b6b74f99916b700e38e4a
Reviewed-on: https://chromium-review.googlesource.com/747682
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49059}
Objects with both dictionary and non-dictionary maps can store their
hash in the {properties} field when they have no other properties.
Bug: chromium:778952
Change-Id: I8ac8c31eaac32116415e3c65cef8dee260dca2c9
Reviewed-on: https://chromium-review.googlesource.com/747272
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49056}
Takes too long on bots to run
Bug:
Change-Id: Ia99717fe943ff6437497425abd3a3cb9999d7564
Reviewed-on: https://chromium-review.googlesource.com/746533
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#49055}
This adds support to the KeyedLoadIC to ignore out of bounds accesses
for Strings and return undefined instead. We add a dedicated bit to the
Smi handler to encode the OOB state and have TurboFan generate appropriate
code for that case as well. This is mostly useful when programs
accidentially access past the length of a string, which was observed and
fixed for example in Babel recently, see
https://github.com/babel/babel/pull/6589
for details. The idea is to also extend this mechanism to Arrays and
maybe other receivers, as reading beyond the length is also often used
in jQuery and other popular libraries.
Note that this is considered a mitigation for a performance cliff and
not a general optimization of OOB accesses. These should still be
avoided and handled properly instead.
This seems to further improve the babel test on the web-tooling-benchmark
by around 1%, because the OOB access no longer turns the otherwise
MONOMORPHIC access into MEGAMORPHIC state.
Bug: v8:6936, v8:7014
Change-Id: I9df03304e056d7001a65da8e9621119f8e9bb55b
Reviewed-on: https://chromium-review.googlesource.com/744022
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49049}
Following up on adding n-ary nodes, this extends the parser and
interpreter to support n-ary logical operations.
Bug: v8:6964
Bug: chromium:731861
Change-Id: Ife2141c389b9abccd917ab2aaddf399c436ef777
Reviewed-on: https://chromium-review.googlesource.com/735497
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49029}
Instead of creating a runtime call for the static class field
initializer in the AST, we do it in the bytecode generator.
This adds the initializer function to the ClassLiteral AST node.
Bug: v8:5367
Change-Id: Iffaa6531511023812011ee19fc96cea9e5c9d3f3
Reviewed-on: https://chromium-review.googlesource.com/736315
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49008}
The status-file flags and the flags from the test case's source code
must always overwrite extra flags set by bots.
Bug: v8:6924
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I0e2aabb69da7cfb8ba6c1c79bd3851462071a6ac
Reviewed-on: https://chromium-review.googlesource.com/732656
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49001}
Because this test uses heap verification, it is quite slow. Split it
into 4 smaller tests to avoid test timeout and allow them to be run
in parallel.
R=ahaas@chromium.org
Bug:
Change-Id: Ie4ac841d1d8215019bb5cfcc335daea6b10ab789
Reviewed-on: https://chromium-review.googlesource.com/738146
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48998}
This adds two tests to verify that the --liftoff flag has the indented
effect, and that Liftoff compilation is off by default.
R=titzer@chromium.org
Bug: v8:6600
Change-Id: Ie7e13184b5068f572b78dbdf7abbcded6d859fc5
Reviewed-on: https://chromium-review.googlesource.com/733561
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48995}
We now represent the SameValue operation explicitly in TurboFan and the
operation can thus participate in all kinds of optimizations. Especially
we get rid of the JSCall node in the general case, which blocks several
optimizations across the call. The general, baseline performance is now
always on par with StrictEqual.
Once the StrictEqual operator is also a simplified operator, we should
start unifying the type based optimizations in SimplifiedLowering.
In the micro-benchmark we go from
testStrictEqual: 1422 ms.
testObjectIs: 1520 ms.
testManualSameValue: 1759 ms.
to
testStrictEqual: 1426 ms.
testObjectIs: 1357 ms.
testManualSameValue: 1766 ms.
which gives the expected result.
Bug: v8:7007
Change-Id: I0de3ff6ff6209ab4c3edb69de6a16e387295a9c8
Reviewed-on: https://chromium-review.googlesource.com/741228
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48994}
... and use them to complete the BigInt function.
Bug: v8:6791
Change-Id: Ia36db86b92d1a0cfcb783516e04d6c0e3750f194
Reviewed-on: https://chromium-review.googlesource.com/737643
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48993}
We can already construct wrapper objects using Object().
R=jkummerow@chromium.org
Bug: v8:6791
Change-Id: Ic4079654ef1fcae2be4b588cb12c2645e199f4f7
Reviewed-on: https://chromium-review.googlesource.com/738089
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48955}
Abstract equality comparison of a BigInt and a String converts the
latter to BigInt. This conversion can fail; since we do not want to
pass a context to the comparison function, we must signal such failure
without throwing an exception.
This CL uses the existing ShouldThrow enum to configure behavior of
String-to-BigInt conversion, moving it out of Object into globals.h.
Bug: v8:6791, v8:6979
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ibb98675079b8392cf03bbcbbbd5556108500a32d
Reviewed-on: https://chromium-review.googlesource.com/734172
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48946}
This flag has been on by default since Chrome 61.
Bug: v8:5549
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I81c34d1d3a7dbd219acce2cdf0cf4917eb484002
Reviewed-on: https://chromium-review.googlesource.com/738312
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48945}
and use a newly-introduced "enum class Operation" in all
other places that so far passed Token::Values around.
Also delete some related dead code along the way.
Bug: v8:6921
Change-Id: I062f396d304aa62298cfeff202e3132a4a5597c1
Reviewed-on: https://chromium-review.googlesource.com/736851
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48944}
It's been on by default since Chrome 61.
Bug: v8:4806
Change-Id: I748d9008d29997667458649d7bf4999e15ff8615
Reviewed-on: https://chromium-review.googlesource.com/737416
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48943}
We have an internal limit of 50000 local variables per wasm function.
This limit is checked when decoding the function body. For asm.js, we
skip function body validation, since by construction the code we
generate is correct. This makes us fail unexpectedly when trying to
(lazily) compile an asm.js function with more than 50000 locals.
Hence, check this limit in the asm parser and bail out if it is
exceeded.
R=mstarzinger@chromium.org
Bug: chromium:775710
Change-Id: I89d2069e133fb0f84947d477ae1ac5eda85571aa
Reviewed-on: https://chromium-review.googlesource.com/732660
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48929}
There is no need to test each operation on each single memory location.
R=titzer@chromium.org, binji@chromium.org
Bug: v8:6994
Change-Id: Ib401fa1dd4db2e1b9c7ee0b48bb0c1cc9e3f9139
Reviewed-on: https://chromium-review.googlesource.com/735149
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48921}
