Not all interface implementations can handle unreachable code
correctly. The baseline compiler will fail if it tries to pop a value
from an empty stack. Instead of fixing this in the interface (the
baseline compiler in this case), this CL fixes this by not calling the
interface for unreachable instructions.
R=titzer@chromium.org
Bug: v8:6600
Change-Id: I567783ce4191ff907b2f90e73b66274728064092
Reviewed-on: https://chromium-review.googlesource.com/715638
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48544}
This adds and explicit check for the constructability of the new.target
value in the lowering of {JSCall} nodes known to call Reflect.construct.
The {JSConstruct} operator does not perform this check and relies on the
implicit validity of new.target in all other use cases.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-768080
BUG=chromium:768080
Change-Id: I7c1921e787bae64ba83de3eb08aa00fc5523e251
Reviewed-on: https://chromium-review.googlesource.com/718100
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48543}
First allocatable register must be same as the argument
count register.
This change fixes problems with optimized tests.
Bug:
Change-Id: I06731c7f27c5f6a761ebdeb3c3c7b2a6c14d7c1d
Reviewed-on: https://chromium-review.googlesource.com/716224
Reviewed-by: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Cr-Commit-Position: refs/heads/master@{#48540}
Unwinding info keeps track of the frame pointer by tracking the changes
to the stack if a frame wasn't constructed. Once the frame is constructed
we no longer need to keep track of this. The code generator informs
the unwinding info writer about frame constructions. This information
was not passed for JSFunctions calls. This cl fixes it to pass also
for JSFunctions.
Bug:
Change-Id: Ia39980039a5f063435fa3b3ab145256909011606
Reviewed-on: https://chromium-review.googlesource.com/718596
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48537}
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}
