The test uses more than 10GB memory in stress mode and causes OOM
failures on TSAN bots.
NOTRY=true
Bug: v8:6924
Change-Id: Ifaab153316432a5c59869ef312b43d84827480df
Reviewed-on: https://chromium-review.googlesource.com/718110
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48532}
There was a helpful TODO telling where it should live.
BUG=v8:5402,v8:6921
Change-Id: Id9022c72c9e7de8d76ea0db964217b766299195d
Reviewed-on: https://chromium-review.googlesource.com/718337
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48524}
This is a reland of 3d023952f2
Original change's description:
> [runtime] Make JSFunction::prototype_or_initial_map field optional.
>
> Functions that don't have prototype need to store neither prototype nor
> initial map, so the |prototype_or_initial_map| field is not required for
> such maps.
>
> Bug: v8:6459
> Change-Id: I4b3066bd6a4fed42c19f217bae82a8bce552bdca
> Reviewed-on: https://chromium-review.googlesource.com/570250
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46840}
Bug: v8:6459
Change-Id: I54e3516ea70474c6d4f873f7b91e74cb8a7d622a
Reviewed-on: https://chromium-review.googlesource.com/583307
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48523}
This file was somehow inexplicably not moved when other parsing files were.
BUG=v8:6921
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Iea92c61f83dbb5a8688c404ba87d35fa58e749b9
Reviewed-on: https://chromium-review.googlesource.com/718197
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48522}
Preparation for sharing more code between deopt fuzzer and normal test runner.
Bug: v8:6917
Change-Id: Id8022c7597544ffddf5d1b0a0d73bb4a9d163fc3
Reviewed-on: https://chromium-review.googlesource.com/715417
Commit-Queue: Michał Majewski <majeski@google.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48521}
These tests use too much memory on MIPS.
Bug:
Change-Id: I9ab15b04ad8cec94ab1b1c022e819a2d802e375d
Reviewed-on: https://chromium-review.googlesource.com/716497
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Cr-Commit-Position: refs/heads/master@{#48518}
This flag describes that the memory defined in a wasm module has a
maximum size. Therefore I think kHasMaximumFlag is more appropriate.
R=titzer@chromium.org
Bug: v8:6921
Change-Id: Ie794d670f74e7f1f9a42822e2f774da85aaaaa4b
Reviewed-on: https://chromium-review.googlesource.com/718198
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48517}
We can bump it up later if there is need.
Taking digit size into account for the max length in digits
makes the max length in bits consistent across architectures.
Bug: v8:6791
Change-Id: Id5205d2d308bbe6a38f8ff1ee19c082bedbeb74a
Reviewed-on: https://chromium-review.googlesource.com/717176
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48514}
In preparation for adding more separate test files.
Bug: v8:6791
Change-Id: I92e2a3ab6fd35e2f902179a005ed9640851ca1b6
Reviewed-on: https://chromium-review.googlesource.com/716927
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48512}
Parser creates a FunctionState for default ctors, which affects the
next_function_is_likely_called logic. PreParser needs to match that logic, so
that Parser and PreParser agree about which functions are skippable.
BUG=v8:5515, chromium:773576
Change-Id: I96cb6f5aa68e74389a863355f70a34693a2d1329
Reviewed-on: https://chromium-review.googlesource.com/712579
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48511}
The current Control::unreachable flag served two things at the same
time: It tracked whether the label of that block is reachable (anyone
jumps / falls through to there), and it tracked whether that block was
ended by an unconditional branch or something similar.
It turns out that these two things cannot be tracked with a single
boolean per control struct. This CL introduces a Merge::reached flag,
which tracks whether a merge point was reached so far.
Also, the boolean flag to track unreachability of instructions within a
block is extended to track implicitly unreachable instructions.
According to the spec, a new block inside of unreachable code must be
validated as reachable code again, and also code after a block which
never returns has to be validated. It's not needed to generate code for
such instructions, however.
This new state will be particularly needed for the baseline compiler.
A follow-up CL will avoid calling interface methods for unreachable
code.
R=titzer@chromium.org
Bug: v8:6600
Change-Id: I54c97a19121eace65e25c448639330d06f61b1c8
Reviewed-on: https://chromium-review.googlesource.com/715637
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48509}
Contrary to other Absolute-bitwise operations, it is not symmetric.
Bug: v8:6791
Change-Id: Id0d57e3cf61177af0b77a3d9d4a4e17e5737ae11
Reviewed-on: https://chromium-review.googlesource.com/714301
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48507}
CheckIf is lowered to DeoptimizeIfNot, but there is no deoptimization
reason given in the deopt if that check fails (the reason is hardcoded
to "no reason"). These deopts are annoying to track down.
This patch makes CheckIf an operator with a DeoptimizeReason parameter,
which is passed through to the DeoptimizeIfNot when lowered.
A couple of checks are converted to give good deoptimize reasons (some
new reasons are introduced), and the others are defaulted to kNoReason
until someone else finds a use for them.
Change-Id: I7e910cc9579ccf978dfe9d270ba7b98c8f6c2492
Reviewed-on: https://chromium-review.googlesource.com/716479
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48506}
The use of object literals comes with Object.prototype as the
prototype. Some of these were required by the specification, but
a change to the specification is proposed in
https://github.com/tc39/ecma402/pull/170 to eliminate this.
Some of them are unobservable, since Object.prototype is always
shadowed, and defineProperty is used rather than ordinary set.
However, just to be cautious, all object literals in
intl.js except the ones that need it (namely the result of
resolvedOptions()) are changed to a null prototype
Tests are in the test262 PR https://github.com/tc39/test262/pull/1220
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I1f684615e60b523441baf31350d752585d8f96d1
Reviewed-on: https://chromium-review.googlesource.com/657839
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48505}
The Scavenger currently requires taking the lock for OLD->NEW processing
and can also take another lock for sweeping a different page.
Since order of pages during scavenge and sweep is unstable this may
result in lock order inversion reports on TSAN when long-running
programms are only executed on a single thread.
The report is a false positve, hence flag it as suppression until we
redesign this particular piece.
No-try: true
Bug: v8:6923
Change-Id: I82355be1c8d83ea61cc21152aeb10b58b1dc4b86
Reviewed-on: https://chromium-review.googlesource.com/716261
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48504}
This makes all inline allocation constructions go through the existing
{AllocationBuilder} helper class. It hence ensures there is a single
place for all sanity checking and and makes use-sites easier to read.
R=jarin@chromium.org
Change-Id: Ib5daf48acd93c631fccdfa095eda1afda7048115
Reviewed-on: https://chromium-review.googlesource.com/709056
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48502}
A minor refactoring of the decoder interface, which makes implementing
the baseline compiler easier.
R=titzer@chromium.org
Bug: v8:6600
Change-Id: Ia5ae66e0e036329767b6e4f1cfcd3ed6a5e4cb74
Reviewed-on: https://chromium-review.googlesource.com/715636
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48498}
This switches all deoptimization events to go through use one single
continuation builtin (i.e. {Builtins::kNotifyDeoptimized}) instead of
handling builtin continuation specially. Fewer moving pieces.
R=jarin@chromium.org
Change-Id: Ic8a2316fa2f5c8717b4d50d1a619b87a38011564
Reviewed-on: https://chromium-review.googlesource.com/712156
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48496}
The degenerate br_table case should be handled specially only in the
graph building consumer. There it is necessary for avoiding the
construction of a degenerate Switch node, which would cause a DCHECK
error in instruction selection.
For other backends, like the baseline compiler, we should handle it as
a br_table, because the signature is different to a br.
Drive-by: Fix redundant validation.
R=titzer@chromium.org
Bug: v8:6600
Change-Id: Ia430b6d251eb1323848977388ed95a112f8c76f7
Reviewed-on: https://chromium-review.googlesource.com/715616
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48494}
This propagates the existing type of a {JSAdd} node back to the newly
created {Allocate} node. There are cases where said type is {None}.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-772720
BUG=chromium:772720
Change-Id: Iab18d2108a789b51db4e405f7f335c5c0ca6f686
Reviewed-on: https://chromium-review.googlesource.com/708796
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48493}
When an immediate does not fit an add instruction we use a temporary register to
hold the value, using movw/movt to encode it. However, in order to remove a use
of r9 in TurboFan's code generator, we need to cope with no scratch registers
being available. That is to say that the destination and source registers are
the same, and `ip` is not available to use.
In this case, we can split an add instruction into a sequence of additions:
```
UseScratchRegisterScope temps(...);
Register my_scratch = temps.Acquire();
__ add(r0, r0, Operand(0xabcd); // add r0, r0, #0xcd
// add r0, r0, #0xab00
```
As a drive-by fix, make the disassembler test fail if we expected a different
number of instructions generated.
Bug: v8:6553
Change-Id: Ib7fcc765d28bccafe39257f47cd73f922c5873bf
Reviewed-on: https://chromium-review.googlesource.com/685014
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#48491}
The VALIDATE macro should only be used for tests that do not have any
side effect, because the side effect will only be executed if
validation is active or in debug builds (because the condition is
DCHECKed there).
The TypeCheckBreak method has side effects since a while, since it
inserts unreachable values on the stack.
This did not lead to failures so far, since we only have validating
users of the WasmFullDecoder. This will change once we have general
lazy compilation of wasm modules, e.g. for tier-up.
R=titzer@chromium.org
Change-Id: I7b34dfd9297122616fa9ebdf899d9f44ca60273b
Reviewed-on: https://chromium-review.googlesource.com/715416
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48490}
Also add tests for Object::SameValue.
R=jkummerow@chromium.org
Bug: v8:6791
Change-Id: I0611044dcfee4c6ba836629cf82d1589135e4ab0
Reviewed-on: https://chromium-review.googlesource.com/712034
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48486}
R=jkummerow@chromium.org
Bug: v8:6791
Change-Id: I7e99a8aa2aa65e78a8d4288f496d496600063bfe
Reviewed-on: https://chromium-review.googlesource.com/712534
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48485}
- remove unused Runtime_GetLanguageTagVariants
- add test for another related bug (chromium:770452) as well as for
chromium:770450 .
Bug: chromium:770450, chromium:770452
Test: intl/general/invalid-locale.js
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I4496a4a5421000faa0e37aed85fea21ceb487998
Reviewed-on: https://chromium-review.googlesource.com/710816
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48483}
