Declare the private field variable in the preparser as well, to be
consistent with the parser.
Bug: v8:5386
Change-Id: I961ddf14e47b99701e2463cab0f4d4de140e1e3a
Reviewed-on: https://chromium-review.googlesource.com/905843
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51154}
We need a deopt point for the case when we fail to find an initial
element from which to begin the reduction step.
Bug: v8:7384
Change-Id: I5e476ddc433be690577677b018639c4c0c70809b
Reviewed-on: https://chromium-review.googlesource.com/906508
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51146}
This is the last piece of the TypedArray constructors that was still
written in JS.
Bug: v8:7102
Change-Id: I7c4dc867b09408caa4eec2873ea7185b6c61a525
Reviewed-on: https://chromium-review.googlesource.com/888751
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51122}
Add a fast-path to Promise#finally, which skips the "then" lookup of the
Promise#then lookup chain is intact, similar to what we already do for
Promise#catch.
Drive-by-fix: Also use the @@species protector to speed up the lookup
of the SpeciesConstructor in Promise#finally.
Bug: v8:7253
Change-Id: If77e779a0188904effc4528beffc8f0bdd7c2efe
Reviewed-on: https://chromium-review.googlesource.com/902283
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51116}
The test required a special runtime function, which did not work in
general but only in the context of that one test. After an offline
discussion we decided that what the test is testing is not worth a
runtime function, since we would also see in other tests if something
goes wrong.
R=clemensh@chromium.org
Bug: v8:7403
Change-Id: I129a189a9df299d409a4a555eae28783e47b97d1
Reviewed-on: https://chromium-review.googlesource.com/901284
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51095}
This adds a new isolate wide Promise#then protector, which guards the
"then" lookup for all JSPromise instances whose [[Prototype]] is the
initial %PromisePrototype%. Thus arbitrary mutations to the
Promise.prototype (i.e. monkey-patching other methods or installing
new functions) no longer sent you down the slow-path. Use this protector
in Promise.prototype.catch and in Promise.resolve.
Drive-by-fix: Restructure the resolve logic a bit and avoid the
expensive and large SameValue check, which can be turned into a simple
reference equal, as the promise in there is known to be a JSPromise
anyways.
Bug: v8:7253
Change-Id: If68b12c6bc6ca9c4d10552ae84854ebc3b5774f9
Reviewed-on: https://chromium-review.googlesource.com/899302
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51085}
Report an error during scope analysis if we're unable to find a
variable proxy for the given private field. This can happen if we try
to access a private field that was not defined or if we're outside
the class scope.
This doesn't correctly throw an early error when pre parsing a top
level function because we don't track it's variables.
Bug: v8:5368
Change-Id: I0a1193fe0ae213c0732fae5d435e150852a8d87d
Reviewed-on: https://chromium-review.googlesource.com/892093
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51082}
A version of the spec change from
https://github.com/tc39/ecma262/pull/988, but applied to the
Async-from-Sync iterator type.
This change does not modify generated bytecode (but maybe it should to
take advantage of load IC feedback for loading "next"). Doing this grows
bytecode by quite a bit, since it's necessary to throw-if-not-an-object
before loading "next" (which currently gets to live in a code stub
instead).
BUG=v8:5855
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I0d2affef664d1069b24c54a553d62e17b49e5a16
Reviewed-on: https://chromium-review.googlesource.com/723136
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51078}
These 2 test have known issues
Change-Id: I4830e0af0f4f1cf7fd1189316356dd1f7dc2c6eb
Reviewed-on: https://chromium-review.googlesource.com/896721
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#51074}
This creates a uniform PerformPromiseThen builtin, which performs the
operation with the same name from the spec, except that it expects the
handlers to be either undefined or callable already, since this is only
relevant for a single callsite (namely Promise.prototype.then).
Introduce a matching operator JSPerformPromiseThen into TurboFan, which
represents this operation and removes the additional checks in case of
Promise.prototype.then based on the information we can derived from the
receiver maps.
This yields a nice 20-25% improvement on Promise.prototype.then, as
illustrated by the following micro-benchmark
```js
const N = 1e7;
function inc(x) { return x + 1; }
function chain(promise) {
return promise.then(inc).then(value => {
if (value < N) chain(Promise.resolve(value));
});
}
console.time('total');
chain(Promise.resolve(0));
setTimeout(console.timeEnd.bind(console, 'total'));
```
which goes from around 1230ms to 930ms with this patch.
Bug: v8:7253
Change-Id: I5712a863acdbe7da3bb8e621887c7b952148c51a
Reviewed-on: https://chromium-review.googlesource.com/899064
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51071}
All tests are sensitive to internal state, which is incompatible with GC
fuzzing.
TBR=ulan@chromium.org
NOTRY=true
Bug: v8:7360
Change-Id: I4b28f40e099b7395e39725aaf6e9e199939ebd9f
Reviewed-on: https://chromium-review.googlesource.com/899087
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51069}
Load mjsunit.js inside the realm as otherwise the functions are not
available in the realm's scope.
This also prints timestamps after each test to easier track down slow
tests.
We also pass --omit-quit to not stop too early.
This also adds the ability to skip certain tests for endurance
fuzzing and skips some tests with known problems.
TBR=ulan@chromium.org,hpayer@chromium.org
Bug: v8:6972, v8:7400
Change-Id: I44464c28bfb10c84f2e59972e7b86945a47ca3b3
Reviewed-on: https://chromium-review.googlesource.com/899008
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51066}
Especially "invalid function" and "invalid type" could contain much
more information.
Drive-by: Remove unused WasmTrapInvalidIndex.
R=ahaas@chromium.org
Change-Id: I7fd72c095eaad94e3e2d9bfe6ab4a9ce0bb4798b
Reviewed-on: https://chromium-review.googlesource.com/897526
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51059}
Previously we would directly take the result from a fulfilled native
promise bypassing the microtask queue. This is observably different
from the spec.
Note: Our variant of the bluebird benchmark is heavily favored towards
fulfilled native promises because we don't use setTimeout (unlike the
original benchmark). I suspect this pattern doesn't appear often in
the wild so it's fine to take this hit for now.
PSA for Perf sheriffs: this is going to tank some benchmarks.
Bug: chromium:800651, v8:5691, v8:6007
Change-Id: Ic273bf2195529424b0d87359d28d5267060d5252
Reviewed-on: https://chromium-review.googlesource.com/895416
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51010}
We still avoid the "then" lookup using the current fast-path
mega-guard in the baseline case, but in TurboFan we simply
constant-fold the "then" lookup in the JSCallReducer. So all
further optimizations on Promise#then in TurboFan will automatically
apply to Promise#catch as well.
Bug: v8:7253
Change-Id: Idf7252157375a0ae3a91c7a3b42c30c5f367c0a8
Reviewed-on: https://chromium-review.googlesource.com/895446
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51008}
This is a reland of 0db74d4974.
Original change's description:
> [test] Random seed processor
>
> 1. --total-timeout-sec now available for ./run-tests.py. It can be
> useful with infinite seed stressing
> 2. random seed dropped from the context. Now JSON progress indicator
> gets it from the list of command args.
>
> Bug: v8:6917
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: I73e535bc8face9b913c696b8d5e3a246fa231004
> Reviewed-on: https://chromium-review.googlesource.com/888524
> Commit-Queue: Michał Majewski <majeski@google.com>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50964}
Bug: v8:6917
Change-Id: I1ea376a4abffce5ab65f4834ea7e6d6011765ffa
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/894204
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michał Majewski <majeski@google.com>
Cr-Commit-Position: refs/heads/master@{#50978}
Async generators didn't correctly handle the situation where one calls
.return on a suspended-at-start async generator and passes a
promise-like object whose awaiting causes a new request to the
generator.
Bug: chromium:805729
Change-Id: I4da13ab5bd97f8c2a2c5373242a2d5e2ab0f7f10
Reviewed-on: https://chromium-review.googlesource.com/891231
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50974}
This reverts commit 0db74d4974.
Reason for revert: https://chromium-swarm.appspot.com/task?id=3b609f9976bac610&refresh=10&show_raw=1
Original change's description:
> [test] Random seed processor
>
> 1. --total-timeout-sec now available for ./run-tests.py. It can be
> useful with infinite seed stressing
> 2. random seed dropped from the context. Now JSON progress indicator
> gets it from the list of command args.
>
> Bug: v8:6917
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: I73e535bc8face9b913c696b8d5e3a246fa231004
> Reviewed-on: https://chromium-review.googlesource.com/888524
> Commit-Queue: Michał Majewski <majeski@google.com>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50964}
TBR=machenbach@chromium.org,sergiyb@chromium.org,majeski@google.com
Change-Id: I2d96ea328cda2d09b01ff455e47c77d567fafe00
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6917
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/894522
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50970}
1. --total-timeout-sec now available for ./run-tests.py. It can be
useful with infinite seed stressing
2. random seed dropped from the context. Now JSON progress indicator
gets it from the list of command args.
Bug: v8:6917
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I73e535bc8face9b913c696b8d5e3a246fa231004
Reviewed-on: https://chromium-review.googlesource.com/888524
Commit-Queue: Michał Majewski <majeski@google.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50964}
Things that don't work yet:
(a) pre parsed scope data is broken
(b) private fields can be accessed outside classes
(c) no early or runtime error for accessing unknown fields
Things that do work:
everything else
Change-Id: I3d58be44e2be73ec50defb42403112a8a5e68c54
Bug: v8:5368
Reviewed-on: https://chromium-review.googlesource.com/865497
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@{#50935}
This adds back an option for interrupt budget available in no-snap
builds. This also adds a fuzzer configuration for numfuzz that enables
fuzzing the interrupt budget option. A new flag --disable-analysis
allows to generally skip the fuzzer's analysis phase, which can be
chosen for interrupt budget, which doesn't support an analysis phase.
Bug: v8:6917
Change-Id: I546dd9ee41c3e0fb027108ef4606a34514f230d4
Reviewed-on: https://chromium-review.googlesource.com/885805
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50929}
Wide suspends have a "wide" (or "extra-wide") bytecode at their offset,
rather than the suspend itself, so they were failing the return check.
Bug: chromium:805765
Change-Id: Iabfc2a2167d09eda2f6885d9100287aadcd8fee9
Reviewed-on: https://chromium-review.googlesource.com/887082
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50923}
Do not overwrite handle values in AddNamedProperty which could cause
invalid handles in combination with CanonicalHandleScope.
Bug: chromium:802333
Change-Id: I373ab60579901bba65336ae3814e466e07392e22
Reviewed-on: https://chromium-review.googlesource.com/873032
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50890}
With the new builtin optimization guard we can just speculatively assume
that the index passed to String#charAt and String#charCodeAt (in
optimized
code) is going to be within the valid range for the receiver. This is
what Crankshaft used to do, and it avoids Smi checks on the result for
String#charCodeAt, since it can no longer return NaN.
This gives rise to further optimizations of these builtins (i.e. to
completely avoid the tagging of char codes), and by itself already
improves the regression test originally reported from 650ms to
610ms.
Bug: v8:7127, v8:7326
Change-Id: I6c160540a1e002a37e44fa7f920e5e8f8c2c4210
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/873382
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50888}
This fixes %StringIteratorPrototype%.next to not mixup
UTF16 and UTF32, and consistently use UTF32 for now.
Bug: chromium:805855
Change-Id: If58e2fe0d9bebd894e12abf8af82881c74388294
Reviewed-on: https://chromium-review.googlesource.com/888741
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50886}
This is a reland of 181ac2b0dc that fixes
the issue with load elimination.
Original change's description:
> [ic] Improve performance of KeyedStoreIC on literal-based arrays.
>
> In mode STORE_AND_GROW_NO_TRANSITION, the handler for elements stores
> used to bail out when seeing a COW array, even if the store that
> installed the handler had been operating on the very same array.
>
> This CL adds support for COW arrays to the mode (and renames it to
> STORE_AND_GROW_NO_TRANSITION_HANDLE_COW).
>
> Bug: v8:7334
> Change-Id: I6a15e8c1ff8d4ad4d5b8fc447745dce5d146c67c
> Reviewed-on: https://chromium-review.googlesource.com/876014
> Commit-Queue: Georg Neis <neis@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50840}
TBR=bmeurer@chromium.org
Bug: v8:7334, chromium:805768
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I3d9c1b08583e08d68a1d30242a25e4a2190c8c55
Reviewed-on: https://chromium-review.googlesource.com/886261
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50885}
A timeout result of randomly combined tests is not a useful indicator.
Therefore we ignore those now. This also prevents timeouts from being
re-run.
TBR=sergiyb@chromium.org
NOTRY=true
Bug: v8:6917
Change-Id: I8e5eb93e2f13067ca5270fb152c3dc1eda1bb3c2
Reviewed-on: https://chromium-review.googlesource.com/888559
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50879}
which was dropped from the proposal:
https://github.com/tc39/proposal-bigint/pull/101
Bug: v8:6791
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I5a3e0024900b34a322a23bcbc4bfdbdffbf8b9d4
Reviewed-on: https://chromium-review.googlesource.com/885510
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50877}
For M65 I added a fast-path for String.p.charCodeAt, which behaves
incorrectly for wide characters. This patch disables the incorrect
fast-path. This is likely no performance regression against M64,
as M64 did not have a fast path for String.p.charCodeAt.
Bug: v8:7371
Change-Id: I8ea9c5da5a583138d87ccb8ffe6d61eba16630b9
Reviewed-on: https://chromium-review.googlesource.com/886782
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50873}
- Introduce new helper IsFastJSArrayWithNoCustomIteration.
- Consolidates all entry array checks...
- Is a fast array (defers to BranchIfFastJSArray)
- No possibility that the Array's iteration protocol has been tampered with
- Introduce new BoolT constant helpers Int32TrueConstant and Int32FalseConstant.
Bug: chromium:804176, chromium:804188
Change-Id: I6b08396484682dc680b431ea564a7a28eeab8108
Reviewed-on: https://chromium-review.googlesource.com/883065
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50867}
In addition I added some comments in the update script which describes
steps which have to be takes the first time you run the script on a
new machine.
R=titzer@chromium.org
Change-Id: Ib360e6fcdcb63eaf225f398eff60041b48f86b62
Reviewed-on: https://chromium-review.googlesource.com/883344
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50863}
This reverts commit 181ac2b0dc.
Reason for revert: TF changes break load elimination.
Original change's description:
> [ic] Improve performance of KeyedStoreIC on literal-based arrays.
>
> In mode STORE_AND_GROW_NO_TRANSITION, the handler for elements stores
> used to bail out when seeing a COW array, even if the store that
> installed the handler had been operating on the very same array.
>
> This CL adds support for COW arrays to the mode (and renames it to
> STORE_AND_GROW_NO_TRANSITION_HANDLE_COW).
>
> Bug: v8:7334
> Change-Id: I6a15e8c1ff8d4ad4d5b8fc447745dce5d146c67c
> Reviewed-on: https://chromium-review.googlesource.com/876014
> Commit-Queue: Georg Neis <neis@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50840}
TBR=neis@chromium.org,ishell@chromium.org,bmeurer@chromium.org
Change-Id: Id841d91b12d199045e0a9c4ddae2c2ead20b5e21
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7334
Reviewed-on: https://chromium-review.googlesource.com/885814
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50860}
When moving arguments for calls into the right registers and stack
slots, we were sometimes overwriting stack slots which would still be
used later to load arguments from. This is because we popped the (wasm)
value stack before executing the register moves, hence the stack
transfer would think the values are not being used any more and reuse
the stack slots.
With this CL, we only pop the arguments from the stack after executing
the stack transfer.
R=ahaas@chromium.org
Bug: v8:7366, v8:6600
Change-Id: I3aa5126c82634fd281959075e91e73465c39abaa
Reviewed-on: https://chromium-review.googlesource.com/883802
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50853}
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}
