Reland of https://chromium-review.googlesource.com/c/v8/v8/+/727893
The crashes should be fixed by https://chromium-review.googlesource.com/c/v8/v8/+/763531

Original change's description:
> Revert "Reland^5 "[turbofan] eagerly prune None types and deadness from the graph""
> 
> This reverts commit ac0661b3.
> 
> Reason for revert: Clusterfuzz unhappy: chromium:783019 chromium:783035
> 
> Original change's description:
> > Reland^5 "[turbofan] eagerly prune None types and deadness from the graph"
> >
> > This gives up on earlier attempts to interpret DeadValue as a signal of
> > unreachable code. This does not work because free-floating dead value
> > nodes, and even pure branch nodes that use them, can get scheduled so
> > early that they get reachable. Instead, we now eagerly remove branches
> > that use DeadValue in DeadCodeElimination and replace DeadValue inputs
> > to value phi nodes with dummy values.
> >
> > Reland of https://chromium-review.googlesource.com/715716
> >
> > Bug: chromium:741225 chromium:776256
> > Change-Id: I251efd507c967d4a8882ad8fd2fd96c4185781fe
> > Reviewed-on: https://chromium-review.googlesource.com/727893
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#49188}
> 
> TBR=jarin@chromium.org,tebbi@chromium.org
> 
> Bug: chromium:741225 chromium:776256 chromium:783019 chromium:783035
> Change-Id: I6a8fa3a08ce2824a858ae01817688e63ed1f442e
> Reviewed-on: https://chromium-review.googlesource.com/758770
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49262}

TBR=jarin@chromium.org,tebbi@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: chromium:741225 chromium:776256 chromium:783019 chromium:783035
Change-Id: I6c02b4beb02997ec34015ed2f6791a93c70f5e36
Reviewed-on: https://chromium-review.googlesource.com/772150
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49429}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/98bbbff..5698e23

Rolling v8/buildtools: https://chromium.googlesource.com/chromium/buildtools/+log/93a751e..9c40f80

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/755a485..fd88dfb

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/4b58512..e70074d

R=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org

Change-Id: I659fc77cdada9b96c42b9b7ea86766b47b6f8352
Reviewed-on: https://chromium-review.googlesource.com/775320Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Thomas Anderson <thomasanderson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49428}

Bug: 
Change-Id: Ibd7c17b4ace25237c3d35466280aff27c44016f0
Reviewed-on: https://chromium-review.googlesource.com/774461Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49427}

This is a reland of 77b0baa6.

Original change's description:
> [wasm] Fix importing wasm-lazy-compile stubs
>
> If two modules use lazy compilation, and one imports a function of
> another, we are unwrapping the js-to-wasm wrapper of the export. This
> was failing so far, because during unwrapping we did not find the wasm
> code.
> This CL fixes this by also recognizing WasmCompileLazy stubs as "wasm
> code".
>
> R=ahaas@chromium.org
>
> Bug: chromium:779569, v8:5991
> Change-Id: If2260c3721e3746a7635b9d0182fd520df2fb773
> Reviewed-on: https://chromium-review.googlesource.com/771672
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49405}

Bug: chromium:779569, v8:5991
Change-Id: I4818e933467bd5a040f1514b8fc18db219a092c7
Reviewed-on: https://chromium-review.googlesource.com/774538Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49426}

We extended the platform API so that it is now possible to post
foreground tasks from background tasks. This new platform API has been
implemented now in all platforms within V8, and in the gin platform in
chrome. The implementation in node.js is still missing. I don't think
there are any node.js tests which use async compilation for
WebAssembly. Therefore we could turn on async compilation again to get
canary coverage.

Bug:chromium:764313

R=titzer@chromium.org, bradnelson@chromium.org
CC=franzih@chromium.org

Change-Id: Ib7f17d84983ad73b936e1de691c18c2f7e06ca5e
Reviewed-on: https://chromium-review.googlesource.com/775338
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49425}

At the moment the inspector tests do not dispose the isolate. This is a
problem because the disposal of the isolate is used to stop the
execution of background tasks. The missing disposal of the isolate
caused flaky tests on the bots recently. With this CL the isolates of
the inspector tests get disposed.

The disposal of the isolate requires the following changes: 1) Store the
isolate in a unique_ptr so that it gets disposed when the isolate-data
gets disposed. It is necessary to use the unique_ptr so that the isolate
gets disposed after other members of isolate-data get disposed.  2)
Dispose all sessions. The reason is that the sessions require the
isolate to exist when they get disposed because they own handles.
Sessions, however, are stored in a static map, whereas the isolate is
stored indirectly in a local variable of the main function. Since local
variables get disposed before the static map is cleared, we have to
clear the map before the end of the main function.

R=kozyatinskiy@chromium.org

Change-Id: Icb33184de254638b6cdfb899e940f18e6064cd69
Reviewed-on: https://chromium-review.googlesource.com/774885Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49424}

When initializing the stack state at a merge point, don't force all
stack slots into registers. Allow constants to stay constants as long
as they are not part of the merge. Otherwise we might break assumptions
of outer blocks which then try to merge a register into a constant and
fail.
Also, add some documentation to {InitMergeStackSlot} to document the
intent of the implementation.

R=titzer@chromium.org

Bug: v8:784050, v8:6600
Change-Id: I3a4c83b446909027be075d3207cb7c748a6b1aad
Reviewed-on: https://chromium-review.googlesource.com/766353Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49423}

Now that UnoptimizedCompileJob only has three stages, move the logic for
stepping between these stages out of UnoptimizedCompileJob and back into
CompilerDispatcher.

BUG=v8:5203

Change-Id: I3bb776e14ef9da801dc9792e9e643b8026135060
Reviewed-on: https://chromium-review.googlesource.com/774743Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49422}

Make the accessors of SharedFunctionInfo instance_class_name take and
return String rather than Object, since it's always a String anyway.

Change-Id: Ic5dacccf3835550e3533356fe7ded37ea107d720
Reviewed-on: https://chromium-review.googlesource.com/774882Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49421}

Align the stack operations in the deoptimizer and take the opportunity to
factorise and improve the code generated for copying.

Bug: v8:6644
Change-Id: I854a975c371936bbf720d56e80dc0c9d68fe7c92
Reviewed-on: https://chromium-review.googlesource.com/763535Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
Cr-Commit-Position: refs/heads/master@{#49420}

With this CL both the AsyncCompileJob and the ModuleCompiler use the new
TaskRunner API to post tasks. With the TaskRunner API it is also valid
to post foreground tasks from background tasks.

R=titzer@chromium.org

Change-Id: Ie3a1b0026f834c25540407eb79abdf67071915fb
Reviewed-on: https://chromium-review.googlesource.com/741590Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49419}

CompileTasks contain a pointer to the isolate. All tasks which have a
pointer to the isolate have to be cancelable to make sure that the task
does not execute after the isolate shut down.

R=rmcilroy@chromium.org

Change-Id: I10b2af0177b5cb60ab1dfdad47529fb8c7301ba0
Reviewed-on: https://chromium-review.googlesource.com/774441Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49418}

Bug: v8:6917
Change-Id: Ic50ed8aca2ef6b6e60eae194cf46c2264a416657
Reviewed-on: https://chromium-review.googlesource.com/774265
Commit-Queue: Michał Majewski <majeski@google.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49417}

Blink wants to use Maybe<T> as a return type of (author) callback
functions, where T can be type void.  So, this patch adds support
of Maybe<void>.

Bug: chromium:778580, chromium:779036
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Id654bafc5ceac8ef6f755902418f250c353a8837
Reviewed-on: https://chromium-review.googlesource.com/771730
Commit-Queue: Yuki Shiino <yukishiino@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49416}

Bug: v8:6917
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I09fb05ac6d4b9b1223118494ce2c89e3ab5de109
Reviewed-on: https://chromium-review.googlesource.com/771870Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michał Majewski <majeski@google.com>
Cr-Commit-Position: refs/heads/master@{#49415}

This ensures that the {Code::builtin_index} field is only set during
allocation of new {Code} objects, making this field truly immutable.

R=jgruber@chromium.org
BUG=v8:6792

Change-Id: Ic793346976183149e2d077e92cb9da3c925ea865
Reviewed-on: https://chromium-review.googlesource.com/774439Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49414}

Simplifies the unoptimized compile job to have only three steps, the
on-main-thread prepare step, the off-thread compile step and the
on-main-thread finalization step.

As part of this change, the compiler dispatcher no longer supports
functions with outer scopeinfo's, since these need to be analysed on the
main thread.

BUG=v8:5203

Change-Id: Ifb378ef81bd47b6f6d4037a3b8acf88660896c4e
Reviewed-on: https://chromium-review.googlesource.com/774558
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49413}

In principle it should be possible that worker threads continue their
execution even after the platform shuts down, because the background
tasks which execute on these threads are not allowed to access the
platform or the the isolate. However, the CompileTasks of the
OptimizingCompileDispatcher crash after the platform shut down. This CL
stops worker threads now when the platform shuts down to prevent any
task to execute after the shutdown of the platform.

R=rmcilroy@chromium.org
CC=machenbach@chromium.org

Change-Id: I3a723c3f6e875f78072600c3c3b95faad3d0ab32
Reviewed-on: https://chromium-review.googlesource.com/774463Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49412}

This CL also narrows the rw scopes on various call sites.

Bug: chromium:774108,v8:6792
Change-Id: I41a6f5dc4948833baaa441fb998ef40d8a832619
Reviewed-on: https://chromium-review.googlesource.com/758370
Commit-Queue: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49411}

Bug: chromium:778668
Change-Id: I0d2cc2166aab93bb7cb5dcc6c72cdb0b335a655f
Reviewed-on: https://chromium-review.googlesource.com/774263
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49410}

This reverts commit 77b0baa6.

Reason for revert: Breaks on win64 bot: https://logs.chromium.org/v/?s=chromium%2Fbb%2Fclient.v8%2FV8_Win64_-_debug%2F20172%2F%2B%2Frecipes%2Fsteps%2FCheck%2F0%2Flogs%2Flazy-compilation%2F0

Original change's description:
> [wasm] Fix importing wasm-lazy-compile stubs
> 
> If two modules use lazy compilation, and one imports a function of
> another, we are unwrapping the js-to-wasm wrapper of the export. This
> was failing so far, because during unwrapping we did not find the wasm
> code.
> This CL fixes this by also recognizing WasmCompileLazy stubs as "wasm
> code".
> 
> R=​ahaas@chromium.org
> 
> Bug: chromium:779569, v8:5991
> Change-Id: If2260c3721e3746a7635b9d0182fd520df2fb773
> Reviewed-on: https://chromium-review.googlesource.com/771672
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49405}

TBR=ahaas@chromium.org,clemensh@chromium.org

Change-Id: If5ab7b9de95ef662a65a6a5b919fa1f13aa492cd
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:779569, v8:5991
Reviewed-on: https://chromium-review.googlesource.com/774518Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49409}

Bug: v8:6972
Change-Id: I116d48f22045cf42cf2123297458640b551d37da
Reviewed-on: https://chromium-review.googlesource.com/768868Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michał Majewski <majeski@google.com>
Cr-Commit-Position: refs/heads/master@{#49408}

Bug: v8:5367
Change-Id: I0c86d7204301665412ef0ef370eb1f0c61123031
Reviewed-on: https://chromium-review.googlesource.com/774264Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49407}

Previously, we had lazy parsing of class constructor disabled when a
class literal had class fields because we were using a reference to
the initializer function variable to load the function and call it.

Instead, in this patch, we use the scope analysis to lookup this
initializer function variable.

Bug: v8:5367
Change-Id: Ib73d7e6abed33c04d1f574e7976bea4869d54757
Reviewed-on: https://chromium-review.googlesource.com/768384
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49406}

If two modules use lazy compilation, and one imports a function of
another, we are unwrapping the js-to-wasm wrapper of the export. This
was failing so far, because during unwrapping we did not find the wasm
code.
This CL fixes this by also recognizing WasmCompileLazy stubs as "wasm
code".

R=ahaas@chromium.org

Bug: chromium:779569, v8:5991
Change-Id: If2260c3721e3746a7635b9d0182fd520df2fb773
Reviewed-on: https://chromium-review.googlesource.com/771672
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49405}

R=hablich@chromium.org
BUG=v8:6792,chromium:774108

Change-Id: I6bb376ea5d1c72f668398fb75f8b2bbea5fdff20
Reviewed-on: https://chromium-review.googlesource.com/771551Reviewed-by: Michael Hablich <hablich@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49404}

This refactors EffectControlLinearizer's LowerTruncateTaggedToBit and
LowerTruncateTaggedPointerToBit such that they share the common code.
This common code will grow further when supporting bigints in a future
CL.

R=jarin@chromium.org

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

When calling the CWasmEntry in order to call from the interpreter to a
wasm function, the given buffer must hold the arguments, and must also
have enough space to hold the return values. We were missing the second
part, hence we failed when there are no parameters, but a return.

R=ahaas@chromium.org

Bug: chromium:784125
Change-Id: I08d417cae60eea64fda8a72e898dbed9f3e88148
Reviewed-on: https://chromium-review.googlesource.com/771633
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49402}

There's not really a point in passing the resume_mode as parameter to
the ResumeGenerator builtin. Instead we could as well just store the
mode to the generator object directly.

Drive-by-fix: On Intel allocate the generator to the new.target register
immediately so we don't need to move it there later.

Bug: v8:6344, v8:6354
Change-Id: I74e98cfffa2b3d72c43d8b6e9fdca03d01c9b4fa
Reviewed-on: https://chromium-review.googlesource.com/774259Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49401}

This reverts commit fac31dfa.

Reason for revert:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Arm%20-%20debug%20builder/builds/10827

Original change's description:
> Update V8 DEPS.
> 
> Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/98bbbff..5698e23
> 
> Rolling v8/buildtools: https://chromium.googlesource.com/chromium/buildtools/+log/93a751e..9c40f80
> 
> Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/755a485..fd88dfb
> 
> Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/4b58512..e70074d
> 
> TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org
> 
> Change-Id: I3b2ea9ca7e62566969e749e36eb42ccbf1bddb9d
> Reviewed-on: https://chromium-review.googlesource.com/774220
> Reviewed-by: v8 autoroll <v8-autoroll@chromium.org>
> Commit-Queue: v8 autoroll <v8-autoroll@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49399}

TBR=v8-autoroll@chromium.org,machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org

Change-Id: I4baaeb7eaeef42a9b2fe62064b4325d399f562ec
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/774438Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49400}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/98bbbff..5698e23

Rolling v8/buildtools: https://chromium.googlesource.com/chromium/buildtools/+log/93a751e..9c40f80

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/755a485..fd88dfb

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/4b58512..e70074d

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

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

- Add {Map/Set/WeakMap/WeakSet}-Constructor microbenchmarks
- Add {Map/Set}-Double microbenchmarks (testing heap number keys)

Bug: v8:6604
Change-Id: Icadd5c81bfb59a58a2a65e119663d3f22637165d
Reviewed-on: https://chromium-review.googlesource.com/773595Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49398}

Bug: chromium:784990
Change-Id: I08c10ec706ccaba765edc7322dc92374863b8a7a
Reviewed-on: https://chromium-review.googlesource.com/771387Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49397}

We need to explicitly rule out negative indices for the out-of-bounds
case, otherwise we can end up with a monomorphic KeyedLoadIC that allows
OOB accesses, but doesn't properly check whether there are properties
with negative integer names on the receiver.

Bug: chromium:784835
Change-Id: Ic3ef5438b76094f024de0c6348183fb62b32088c
Reviewed-on: https://chromium-review.googlesource.com/774278Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49396}

Mul/MinS/MaxS/AddSaturateU/SubSaturateU/MinU/MaxU, Eq/Ne

Bug: 
Change-Id: I197712c37dcbc6648be5fd040ca23f2ea777a4f3
Reviewed-on: https://chromium-review.googlesource.com/760156
Commit-Queue: Jing Bao <jing.bao@intel.com>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49395}

The option lets us use the function in cases where we cannot use the current
version due to restrictions on src and dst. This will be useful for some arm64
builtins when we pad the stack arguments, where we will need to copy the
existing arguments either one slot up or one slot down in memory.

Bug: v8:6644
Change-Id: I75281cdc9fa6812e3b24bf5756057c93305cbb95
Reviewed-on: https://chromium-review.googlesource.com/771711Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Cr-Commit-Position: refs/heads/master@{#49394}

TBR=jgruber@chromium.org

Bug: v8:7078
Change-Id: I032bb6c8a9d1079ac9d8f69f6bef3de32f6e78ca
Reviewed-on: https://chromium-review.googlesource.com/772250Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49393}

Beside blocks, do also generate loops.
Also, generalize generation of breaks such that they can happen
anywhere, even outside of a block or loop.

R=eholk@chromium.org

Change-Id: Ib2f8c75913e97f331ec105fd87fc882bc5c04864
Reviewed-on: https://chromium-review.googlesource.com/771610Reviewed-by: Eric Holk <eholk@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49392}

Even though a previous patch made the number of slots pushed/claimed on
the stack aligned, the boundary between frames was not a multiple of
two slots as well. We were pushing the number of arguments (which belongs
in the stub's frame) together with the arguments to pass to the
constructor function (which belong to the frame of the constructor
function). Those need to be separated so we can drop the arguments without
messing up the alignment.

Bug: v8:6644
Change-Id: I839a4ab9caf451623fbcf03dd8a8afe5879fef99
Reviewed-on: https://chromium-review.googlesource.com/771670Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Cr-Commit-Position: refs/heads/master@{#49391}

We can use v8::ArrayBuffer to store struct.

R=dgozman@chromium.org

Bug: none
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I6c4e994e3a8b0a19ad06f89dfadf808f8c6a68e6
Reviewed-on: https://chromium-review.googlesource.com/772036Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49390}