This patch also changes the visitor of BytecodeArray to use
BytecodeArray::BodyDescriptor.

BUG=chromium:733159

Change-Id: I2ac72c97ec51996b5b100c447b543895180f4f78
Reviewed-on: https://chromium-review.googlesource.com/535674Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45955}

This reverts commit f577b2bb.

Reason for revert: Failure on https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20verify%20csa/builds/1978

Original change's description:
> [frames] Make interpreted frame detection stricter
> 
> When iterating over stack frames, make the interpreted frame detection
> require that the frame header contains the bytecode array.
> 
> Currently, the stack frame iterator supports bytecode handlers that
> don't create stack frames by checking if the top of the stack (i.e. the
> return address) is the interpreter entry trampoline. However, optimized
> code tail called from the interpreter entry trampoline can move the
> stack pointer without clearing the stack, which means it can end up with
> a pointer into the interpreter entry trampoline on the top of its stack
> (in an uninitialized value), and be interpreted as an interpreted frame.
> 
> To avoid such optimized code frames being interpreted as interpreted
> frames, we now additionally test the frame header, to see if it contains
> a BytecodeArray.
> 
> Change-Id: I4bafcf0f7ce3c973a2e5a312f054d72312bb8a70
> Reviewed-on: https://chromium-review.googlesource.com/535646
> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45951}

TBR=kozyatinskiy@chromium.org,leszeks@chromium.org

Change-Id: Icc009cf97b816f6c33574782ed9ab473387886c9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/535478Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45954}

Bug: chromiume:733118
Change-Id: Ic144342d86fc84bf5c4700cec357ac8f3c6b2cb3
Reviewed-on: https://chromium-review.googlesource.com/535522Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45953}

Bug: chromium:733059, chromium:724947
Change-Id: Id7abc22ee0975cd609cc06a02552f68e9e0077e8
Reviewed-on: https://chromium-review.googlesource.com/535596
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45952}

When iterating over stack frames, make the interpreted frame detection
require that the frame header contains the bytecode array.

Currently, the stack frame iterator supports bytecode handlers that
don't create stack frames by checking if the top of the stack (i.e. the
return address) is the interpreter entry trampoline. However, optimized
code tail called from the interpreter entry trampoline can move the
stack pointer without clearing the stack, which means it can end up with
a pointer into the interpreter entry trampoline on the top of its stack
(in an uninitialized value), and be interpreted as an interpreted frame.

To avoid such optimized code frames being interpreted as interpreted
frames, we now additionally test the frame header, to see if it contains
a BytecodeArray.

Change-Id: I4bafcf0f7ce3c973a2e5a312f054d72312bb8a70
Reviewed-on: https://chromium-review.googlesource.com/535646Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45951}

Context::Lookup method should support Module variables.

Bug: chromium:717670
Change-Id: I58d3448b9048c7f9dd7ab8b720803b3503cf91ae
Reviewed-on: https://chromium-review.googlesource.com/519389
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45950}

This cleanup is the result of trying to modify the `Assembler::addrmod1` method
and realising it's very easy to break it. It handles three groups of
instructions with different operands and uses `r0` when a register is not used:

- General case:            rd, rn, (rm|rm shift #imm|rm shift rs)
- Comparison instructions:     rn, (rm|rm shift #imm|rm shift rs)
- Move instructions        rd,     (rm|rm shift #imm|rm shift rs)

Let's use `no_reg` instead of `r0` with explicit checks and assertions so that
it's clear this method is used with multiple types of instructions.
Additionaly, keep the order of operands as "rd", "rn", "rm".

As drive-by fixes, I've taken the opportunity to add a few helper methods to the
`Operand` class.

Bug: 
Change-Id: If8140d804bc90dea1d3c186b3cee54297f91462a
Reviewed-on: https://chromium-review.googlesource.com/531284
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45949}

BUG=

Review-Url: https://codereview.chromium.org/2922983002
Cr-Commit-Position: refs/heads/master@{#45948}

Until now, ATOM regexps (i.e. simple patterns don't require regexp matching
logic but can use generic string matching algorithms instead) have always gone
through the slow runtime.

This CL implements a fast path in CSA which simply calls StringIndexOf
internally and then sets up the last-match-info as required.

Local microbenchmarks show a 30% improvement for RE.p.exec on ATOM regexps,
and a 5% improvement on Octane/RegExp.

Bug: v8:6462
Change-Id: I35b4c5caf416fa35fe388dd58e34dea55b098d09
Reviewed-on: https://chromium-review.googlesource.com/535455
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45947}

Simplifies the implementation of IteratorClose in IteratorBuiltinsAssembler, and makes clear that it is only invoked when an exception occurs. Adds exception handling support to GetIterator, IteratorStep, and IteratorCloseOnException.

Moves the Promise.all resolveElement closure and it's caller to
builtins-promise-gen.cc.

Instead of creating an internal array (and copying its elements into a
result
array), a single JSArray is allocated, and appended with
BuildAppendJSArray(),
falling back to %CreateDataProperty(), and elements are updated in the
resolve
closure the same way. This should always be unobservable.

This CL increases the size of snapshot_blob.bin on an x64.release build
by 8.51kb

BUG=v8:5343
R=cbruni@chromium.org, gsathysa@chromium.org, jgruber@chromium.org, hpayer@chromium.org, tebbi@chromium.org

Change-Id: I29c4a529154ef49ad65555ce6ddc2c5b7c9de6b3
Reviewed-on: https://chromium-review.googlesource.com/508473
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45946}

Review-Url: https://codereview.chromium.org/2937943002
Cr-Commit-Position: refs/heads/master@{#45945}

Bug: v8:6474

Change-Id: I24d067ac77c2cb557d0b3f6e2c8c512761c160f1
Reviewed-on: https://chromium-review.googlesource.com/531384
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45944}

This removes support for reconstructing stack frames for full-codegen
from the deoptimizer. We no longer deoptimize to such code. This also
allows us to remove the {DeoptimizationOutputData} data structure.

R=jarin@chromium.org
BUG=v8:6409

Change-Id: Id28ef05aa985b6877b5c91926a7d7d0d6d6e661d
Reviewed-on: https://chromium-review.googlesource.com/535537Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45943}

These were too aggressively de-inlined as part of
https://chromium-review.googlesource.com/c/528102 .

BUG=chromium:733161

Change-Id: I88e9f969dcd6142cbbbb2662edd8108ad687c522
Reviewed-on: https://chromium-review.googlesource.com/535640Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45942}

NOTRY=true
NOTREECHECKS=true
TBR=vogelheim@chromium.org

Bug: chromium:726584
Change-Id: I7a20b8897e6db681acec76c135e4d17674e17729
Reviewed-on: https://chromium-review.googlesource.com/535517
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45941}

BUG=chromium:694255
TBR=mlippautz@chromium.org

Change-Id: I5c6fbb392d68a348e3a8b3fb52368232883e9931
Reviewed-on: https://chromium-review.googlesource.com/535594Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45940}

This removes the ability to prepare bailout points in code generated by
the {FullCodeGenerator}. Such code is no longer used as the target of
deoptimization attempts, hence storing deoptimization data is obsolete.

R=jarin@chromium.org
BUG=v8:6409

Change-Id: I3200182a6e88014ce953881fa0d1ac0bc65ee424
Reviewed-on: https://chromium-review.googlesource.com/533153Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45939}

With concurrent marking the write barrier should trigger even if the
object is black because the concurrent marker could have fetched
object field before marking the object black.

BUG=chromium:694255

Change-Id: Icacc5672defeec85936e37d7d06780c74b97732c
Reviewed-on: https://chromium-review.googlesource.com/533614Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45938}

TBR=ulan@chromium.org
NOTRY=true

Bug: chromium:694255
Change-Id: I430fad8916112141eec60914d73640b31d3da9d4
Reviewed-on: https://chromium-review.googlesource.com/535555Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45937}

R=machenbach@chromium.org
BUG=v8:6408

Change-Id: I3c785acd30d8feb0541e9acdf0c44225a01cb71c
Reviewed-on: https://chromium-review.googlesource.com/533154Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45936}

For unknown Argument object Maps we have to expect that constants fields
are kept on the Map.

Bug: chromium:729597
Change-Id: I110f77455ce434a431c8de27d021b1a5deb86f30
Reviewed-on: https://chromium-review.googlesource.com/532900Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45935}

This completes refactoring started in 0a355777.

Bug: v8:6474
Change-Id: Ia2ea66e10e4f1d55551fe145f67f4021ae254b23
Reviewed-on: https://chromium-review.googlesource.com/532997
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45934}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/05cc70d..4280b28

Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/e6b02f2..597f96e

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/fbd95a5..b7068ad

TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org

Change-Id: I338f86ce6466baded9fcbaea5ed0c00739a661b3
Reviewed-on: https://chromium-review.googlesource.com/535313Reviewed-by: v8 autoroll <v8-autoroll@chromium.org>
Commit-Queue: v8 autoroll <v8-autoroll@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45933}

Revert of [wasm] Increase WebAssembly.Memory maximum size to ~2GB (patchset #10 id:200001 of https://codereview.chromium.org/2903153002/ )

Reason for revert:
gc stress failure:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20gc%20stress/builds/11122

Original issue's description:
> [wasm] Increase WebAssembly.Memory maximum size to 2GB
>
> BUG=v8:6478, chromium:729768
>
> R=bradnelson@chromium.org, eholk@chromium.org
>
> Review-Url: https://codereview.chromium.org/2903153002
> Cr-Commit-Position: refs/heads/master@{#45931}
> Committed: https://chromium.googlesource.com/v8/v8/+/7e6ed62071d2756688a23bd6dac096b0d4660b5d

TBR=bradnelson@chromium.org,eholk@chromium.org,gdeepti@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:6478, chromium:729768

Review-Url: https://codereview.chromium.org/2935243002
Cr-Commit-Position: refs/heads/master@{#45932}

BUG=v8:6478, chromium:729768

R=bradnelson@chromium.org, eholk@chromium.org

Review-Url: https://codereview.chromium.org/2903153002
Cr-Commit-Position: refs/heads/master@{#45931}

It is only attached to the global object if the --harmony-sharedarraybuffer
flag is enabled, but this allows more objects to be added to the snapshot which
seems to reduce the amount of heap memory used per context.

Bug: chromium:724053
Change-Id: I5d1115a0e3ed9abf41cb3ab80d19d622cbef7b93
Reviewed-on: https://chromium-review.googlesource.com/534594Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45930}

- Eliminates S32x4Shuffle, S16x8Shuffle opcodes. All shuffles are subsumed
  by S8x16Shuffle. This aligns us with the latest WASM SIMD spec.

LOG=N
BUG=v8:6020

Review-Url: https://codereview.chromium.org/2923103003
Cr-Commit-Position: refs/heads/master@{#45929}

LOG=N
BUG=v8:6020

Review-Url: https://codereview.chromium.org/2928853002
Cr-Commit-Position: refs/heads/master@{#45928}

Builtins::kReturnReceiver is used for the Symbol.iterator function on
iterators, and just returns the iterator itself. For example, for-of
or yield* with a generator will first call generator[Symbol.iterator](),
which simply returns the generator itself. Inlining this particular
builtin into TurboFan is trivial and avoids that call completely,
enabling more possibilities for LoadElimination and EscapeAnalysis
to get rid of even more checks in common generator code.

BUG=v8:6344,v8:6351,v8:6354
R=jgruber@chromium.org

Review-Url: https://codereview.chromium.org/2938683002
Cr-Commit-Position: refs/heads/master@{#45927}

Change-Id: Ie79607b16270a50ef74261ee8e34a3f1321454c1
Reviewed-on: https://chromium-review.googlesource.com/534233Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45926}

Port the baseline implementation of Object.prototype.isPrototypeOf to
the CodeStubAssembler, sharing the existing prototype chain lookup logic
with the instanceof / OrdinaryHasInstance implementation. Based on that,
do the same in TurboFan, introducing a new JSHasInPrototypeChain
operator, which encapsulates the central prototype chain walk logic.

This speeds up Object.prototype.isPrototypeOf by more than a factor of
four, so that the code

  A.prototype.isPrototypeOf(a)

is now performance-wise on par with

  a instanceof A

for the case where A is a regular constructor function and a is an
instance of A.

Since instanceof does more than just the fundamental prototype chain
lookup, it was discovered in Node core that O.p.isPrototypeOf would
be a more appropriate alternative for certain sanity checks, since
it's less vulnerable to monkey-patching. In addition, the Object
builtin would also avoid the performance-cliff associated with
instanceof (due to the Symbol.hasInstance hook), as for example hit
by https://github.com/nodejs/node/pull/13403#issuecomment-305915874.
The main blocker was the missing performance of isPrototypeOf, since
it was still a JS builtin backed by a runtime call.

This CL also adds more test coverage for the
Object.prototype.isPrototypeOf builtin, especially when called from
optimized code.

CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
BUG=v8:5269,v8:5989,v8:6483
R=jgruber@chromium.org

Review-Url: https://codereview.chromium.org/2934893002
Cr-Commit-Position: refs/heads/master@{#45925}

They were already implemented mostly in C++ (only error/negative
cases were handled in script), so this is mostly just a cleanup.
Only the constructors remain in script after this CL.

Bug: v8:6354
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I5b3579337a8e33dc30d49c2da5cfd42baec697bb
Reviewed-on: https://chromium-review.googlesource.com/531670Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45924}

Bug: chromium:724947
Change-Id: I287677b2cf18154bcbc0d0a5b15d12455d73d0c3
Reviewed-on: https://chromium-review.googlesource.com/534153Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45923}

Bug: v8:6461
Change-Id: Iafabf2d53aa6492b78a9e5ae683f010453bb195d
Reviewed-on: https://chromium-review.googlesource.com/533014Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45922}

TracingCpuProfiler test updates the current plaform while
concurrent marking is running.

This patch also disables stress-incremental-marking for
mjsunit/regress-430201.

BUG=chromium:694255

Change-Id: I85ff538c47bce0300cde3204989ef3f9512b805f
Reviewed-on: https://chromium-review.googlesource.com/533873Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45921}

Bug: 
Change-Id: I5ea0e072c3ac100a6f3bed62a9a4d2c11d2b7c9a
Reviewed-on: https://chromium-review.googlesource.com/533414
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45920}

Help the compiler a bit by moving the loads into the ctor.

Bug: 
Change-Id: I62deff0ee7252ea78dfec380e791ec958886005d
Reviewed-on: https://chromium-review.googlesource.com/533534Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45919}

Bug: chromium:731351
Change-Id: I810986cba2f575da9de2c4bb70c250784148eeb5
Reviewed-on: https://chromium-review.googlesource.com/532634
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45918}

Introduce DEFINE_FIELD_OFFSET_CONSTANTS macro for defining a contiguous
sequence of field offsets.
In addition, this CL turns last two Smi fields to int fields.

Bug: v8:6470
Change-Id: I12a6ad8d7b444772dbc01bba6734080f1d5eccdc
Reviewed-on: https://chromium-review.googlesource.com/532913Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45917}

Bug: 
Change-Id: Ia347ed26ae93730a6bc58bcd6f5edb19b8ded5a9
Reviewed-on: https://chromium-review.googlesource.com/533413
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45916}