Change-Id: I1022cceafed0b27fa2fb5f0f30a1b75fd3a27f3f
Reviewed-on: https://chromium-review.googlesource.com/c/1260258Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56381}

Holes in double arrays are encoded using a signaling NaN bit pattern.
Previously when checking for Float64 holes we did an expensive bit
check always, but most values aren't even NaNs in reality. So we changed
the CheckFloat64Hole operator to first check if the value is a NaN at
all and only if so, perform the concrete bit check (in deferred code).

This improves the array copying test case mentioned in the bug from

  copyPacked: 123 ms.
  copyHoley: 157 ms.

to

  copyPacked: 122 ms.
  copyHoley: 125 ms.

so there's almost no penalty for double holey arrays anymore in case of
copying arrays. This change seems to yield an overall ~1% on the Kraken
benchmark.

Bug: v8:8264
Change-Id: Id7393867ec96fdc080e24d326039f80a9d7b6646
Reviewed-on: https://chromium-review.googlesource.com/c/1261519Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56380}

AtomicPair operations are only available with some instructions
introduced in version R6. Add support for needed instructions.

Change-Id: I808d6ed5b5efafd638846ec599941ebc71d90e23
Reviewed-on: https://chromium-review.googlesource.com/c/1251526Reviewed-by: Ivica Bogosavljevic <ibogosavljevic@wavecomp.com>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Sreten Kovacevic <skovacevic@wavecomp.com>
Cr-Commit-Position: refs/heads/master@{#56379}

We want to replace all uses of CallOnForegroundThread eventually by the
new TaskRunner API so that we can eventually deprecate the old API and
remove it.

R=ulan@chromium.org

Bug: v8:8238
Change-Id: I7e451eddf05f1f7f273c5cfd57d82737380f3f02
Reviewed-on: https://chromium-review.googlesource.com/c/1261145Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56378}

This makes it more explicit what we're actually parsing and allows us to omit
unnecessary checks.

Change-Id: I3e22ab4af0f23cee51cb689dd6377565e42f9bad
Reviewed-on: https://chromium-review.googlesource.com/c/1260943Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56377}

Use Check rather than if peek() + Expect/Consume

Change-Id: I5bc98288a751234117a2708c17dbb68008af5838
Reviewed-on: https://chromium-review.googlesource.com/c/1261144Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56376}

We want to replace all uses of CallOnForegroundThread eventually by the
new TaskRunner API so that we can eventually deprecate the old API and
remove it.

R=leszeks@chromium.org

Bug: v8:8238
Change-Id: I6a1e55fe431225ffe4c77cd3387f3b060eb43edf
Reviewed-on: https://chromium-review.googlesource.com/c/1256866Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56375}

The goal is to remove CL to remove the confusing implications for
full poisoning.

This is an alternative to
https://chromium-review.googlesource.com/c/chromium/src/+/1253341
where chrome has to work around our implication system.

In the optimizing compiler, we already have a bottleneck for setting
mitigation level in src/compiler/pipeline.cc, so it is easy to change
back to partial mitigations.

Bug: chromium:888892
Change-Id: I01de7ed7bb91e8b06f8f79cc2d90657a0600892a
Reviewed-on: https://chromium-review.googlesource.com/c/1252985Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56374}

This had bit-rotten a little and did no longer work for compiling
webassembly code. Also, correct the output of live ranges so that it
can be parsed again.

Bug: v8:8238
Change-Id: I09c2d8bd604f3be12ead8b968f0b70287fad65f1
Reviewed-on: https://chromium-review.googlesource.com/c/1256864
Commit-Queue: Stephan Herhut <herhut@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56373}

For NumberModulus and SpeculativeNumberModulus there's no observable
difference between 0 and -0 for the right hand side, since both of them
result in NaN (in general the sign of the right hand side is ignored
for modulus in JavaScript). For the left hand side we can just propagate
the zero identification part of the truncation, since we only care about
-0 on the left hand side if the use nodes care about -0 too.

This further improves the Kraken/audio-oscillator test from around 67ms
to 64ms.

Bug: v8:8015, v8:8178
Change-Id: I1f51d42f7df08aaa28a9b0ddd3177df6b76be98c
Reviewed-on: https://chromium-review.googlesource.com/c/1260024
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56372}

This is a follow-up cleanup to treat NumberRound like the other rounding
operations (NumberFloor, NumberCeil and NumberTrunc).

Bug: v8:8015
Change-Id: I2b2fbc7f0319497d16ccb7472595eeb68be1f51d
Reviewed-on: https://chromium-review.googlesource.com/c/1260403Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56371}

The slow-path of CheckedInt32Mod(x,y) when x is found to be negative
still had the power of two right hand side optimization, and thus would
perform a dynamic check on y. Now the same dynamic check was done for
the fast-path, and the word operations for this check were pure, leading
to weird bit materialization in TurboFan (due to sea of nodes). But
there's not really a point to be clever for the slow-path, so we just
insert the Uint32Mod operation directly here, which completely avoids
the problem.

This improves the Kraken/audio-oscillator test from around 73ms to 69ms.

Bug: v8:8069
Change-Id: Ie8ea667136c95df2bd8c5ba56ebbc6bd2442ff23
Reviewed-on: https://chromium-review.googlesource.com/c/1259063Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56370}

When converting a Signed32\/MinusZero value from Word32 to Float64
representation or just passing it through as Word32 (with potential
type checks on it) we don't need to worry about -0 as long as the uses
identify 0 and -0.

Drive-by-fix: Fix the CheckChange() helper in the representation
changer test to pass Truncation::Any() by default.

Bug: chromium:891639, chromium:891612, chromium:891627, v8:8015, v8:8178
Change-Id: I06948ec0cdb8e778cb3678124ef927277a5f40ee
Reviewed-on: https://chromium-review.googlesource.com/c/1258902Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56369}

Adds new VisitModes VISIT_ALL_BUT_READ_ONLY and
VISIT_STRONG_FOR_SERIALIZATION.

GC-related methods like MarkReachableObjects now now use
VISIT_ALL_BUT_READ_ONLY instead of VISIT_ALL. All GC-related VisitModes
skip iterating over the read-only roots.

All Serializer methods should always use a _FOR_SERIALIZATION value to
ensure they do visit the read-only roots.

Also adds RootsTable::read_only_roots_begin and end methods.

Bug: v8:7464
Change-Id: I468d7ae9f345d9fc0e10837f01dc5b92bd996412
Reviewed-on: https://chromium-review.googlesource.com/c/1256245Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56368}

Often, tasks just need to call a single API method. By implementing
such tasks via a lambda, we save a lot of boilerplate. Additionally,
since lambdas are defined inside other function bodies, they have
access to private methods, which sometimes allows for better
encapsulation.

This CL introduces {CancelableLambdaTask} and
{CancelableIdleLambdaTask} and uses them to replace some custom tasks.
More can be refactored later.

R=ahaas@chromium.org

Bug: v8:8238
Change-Id: I88bd2c9bd57ebc32d082528f2e4251d741a0d021
Reviewed-on: https://chromium-review.googlesource.com/c/1256773
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56367}

This is a hack to make sure the atomic operations don't
use the kRootRegister ebx before code generation.

I've filed v8:8254 to track that a larger clean-up operation
will be needed to remove this and other hacks.

Change-Id: I6f28f01ba2f96257a9e65eaa36fcad66b01906dd
Bug: v8:6666, v8:8254
Reviewed-on: https://chromium-review.googlesource.com/c/1256862Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56366}

This reverts commit ef2a19a2.

Reason for revert: Broken layout tests: https://ci.chromium.org/p/chromium/builders/luci.chromium.try/linux_chromium_rel_ng/201392

Original change's description:
> Add fast path for spreading primitive strings.
> 
> This improves the performance on primitive strings of
> IterableToListWithSymbolLookup, which implements the
> CreateArrayFromIterable bytecode. The fast path is only
> taken if the string iterator protector is valid (that is,
> String.prototype[Symbol.iterator] and
> String.prototype[Symbol.iterator]().next are untouched).
> 
> This brings spreading of primitive strings closer to the
> performance of the string iterator optimizations.
> (see https://docs.google.com/document/d/13z1fvRVpe_oEroplXEEX0a3WK94fhXorHjcOMsDmR-8/).
> 
> Bug: chromium:881273, v8:7980
> Change-Id: Ic8d8619da2f2afcc9346203613a844f62653fd7a
> Reviewed-on: https://chromium-review.googlesource.com/1243110
> Commit-Queue: Hai Dang <dhai@google.com>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56329}

TBR=ulan@chromium.org,neis@chromium.org,sigurds@chromium.org,bmeurer@chromium.org,dhai@google.com

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

Bug: chromium:881273, v8:7980
Change-Id: I4868160b87bdebf9fd2ff346aefd4cdce23681a1
Reviewed-on: https://chromium-review.googlesource.com/c/1261022Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56365}

This undoes the workaround from https://crrev.com/c/1223426.

Bug: chromium:887888
Change-Id: Id7a68354b1f1020d7d001ba4120be8a11f896067
Reviewed-on: https://chromium-review.googlesource.com/c/1260942
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56364}

This introduces a new flag --async-stack-traces, which enables zero-cost
async stack traces. This enriches the non-standard Error.stack property
with async stack frames computed from walking up the promise chains and
collecting all the await suspension points along the way. In Error.stack
these async frames are marked with "async" to make it possible to
distinguish them from regular frames, for example:

```
Error: Some error message
    at bar (<anonymous>)
    at async foo (<anonymous>)
```

It's zero-cost because no additional information is collected during the
execution of the program, but only the information already present in the
promise chains is used to reconstruct an approximation of the async stack
in case of an exception. But this approximation is limited to suspension
points at await's in async functions. This depends on a recent ECMAScript
specification change, flagged behind --harmony-await-optimization and
implied the --async-stack-traces flag. Without this change there's no
way to get from the outer promise of an async function to the rest of
the promise chain, since the link is broken by the indirection introduced
by await.

For async functions the special outer promise, named .promise in the
Parser desugaring, is now forcible allocated to stack slot 0 during
scope resolution, to make it accessible to the stack frame construction
logic. Note that this first prototype doesn't yet work fully support
async generators and might have other limitations.

Bug: v8:7522
Ref: nodejs/node#11865
Change-Id: I0cc8e3cdfe45dab56d3d506be2d25907409b01a9
Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces
Reviewed-on: https://chromium-review.googlesource.com/c/1256762
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56363}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/3d9873f..29568c1

Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/0daedf7..b250ec1

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

Change-Id: Ifbe08a9e1f1dc077c7e5e253c483dfab6a648ebe
Reviewed-on: https://chromium-review.googlesource.com/c/1260255Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#56362}

Bug: v8:7684
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I0f83c37dd1f5bd85dc3f444b6583fda404812b92
Reviewed-on: https://chromium-review.googlesource.com/c/1260402Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56361}

When projection nodes are optimized, TempRegisters are used, which
don't check to see if the registers are already in use.
UseUniqueRegisters instead.

Change-Id: I6a327098067daa3328355380da666d404fcc8b46
Bug: v8:8202, v8:6532
Reviewed-on: https://chromium-review.googlesource.com/c/1259107Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56360}

Bug: v8:7834
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I146f32f9f71beb58efefa12ffcf7beca67d6c850
Reviewed-on: https://chromium-review.googlesource.com/c/1259865
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56359}

Chrome side changes in https://chromium-review.googlesource.com/c/chromium/src/+/1255629

Bug: v8:8250
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Icba3e73217919c71925774d0cfbab69a7ffa1bba
Reviewed-on: https://chromium-review.googlesource.com/c/1255628Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56358}

The proposal is currently at Stage 3 of the TC39 process.

Repository: https://github.com/tc39/proposal-well-formed-stringify

Bug: v8:7782
Change-Id: Id46054ec6873ca2d1bc8113b8c82b58b1b8427d2
Reviewed-on: https://chromium-review.googlesource.com/c/1257921Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56357}

fixed Abort() calling sequence on platforms with function descriptors by taking
function descriptor of the External Reference object into account when calling
C code.

Change-Id: I54c04a5f1774f2768380cc5c95b1b807204335ce
Reviewed-on: https://chromium-review.googlesource.com/c/1258186Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#56356}

In particular, recognize builtins' values accesses and direct accesses
to external reference values. For example:

  REX.W leaq rax,[r13+0x47a0]
  REX.W leaq rbx,[r13+0x80b0]

turns into

  REX.W leaq rax,[r13+0x47a0] (builtin (RecordWrite))
  REX.W leaq rbx,[r13+0x80b0] (external value (Isolate::context_address))

Bug: v8:8238
Change-Id: I3b049a1e82de7450bf04135c0c8d76b4dca4ee10
Reviewed-on: https://chromium-review.googlesource.com/c/1256830Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56355}

unordered_map is supposedly faster on deleting items.

BUG=chromium:889545

Change-Id: Id92d9d663e8b9ab2978b8016ef5dccfc93dc104e
Reviewed-on: https://chromium-review.googlesource.com/1255554Reviewed-by: Ali Ijaz Sheikh <ofrobots@google.com>
Commit-Queue: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56354}

Change-Id: Ic99e2e02ae644382873d9cf0621145bcde23b6b2
Reviewed-on: https://chromium-review.googlesource.com/1257807Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#56353}

In C to WASM stubs, when number of parameters is more than 5, or
anything requires stack arguments, current linkage is faulty
because of missing STACK_SHADOW_WORDS

Drive-by: Also cleanup s390 code which is not supported anymore.

R=joransiu@ca.ibm.com

Change-Id: I7405c32fd94e158e6868f9ce7d4390c995078dbb
Reviewed-on: https://chromium-review.googlesource.com/c/1257269Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#56352}

This is part of clean-up for a new Clang warning that we'd like to
enable. This patch addresses all warnings from V8 that I saw in a full debug
build of Chromium on Linux.

../../v8/src/reloc-info.h:405:18: warning: explicitly defaulted move assignment
operator is implicitly deleted [-Wdefaulted-function-deleted]
  RelocIterator& operator=(RelocIterator&&) = default;
                 ^
../../v8/src/reloc-info.h:447:13: note: move assignment operator of
'RelocIterator' is implicitly deleted because field 'mode_mask_' is of
const-qualified type 'const int'
  const int mode_mask_;
            ^

../../v8/src/wasm/baseline/liftoff-compiler.cc:111:36: warning: explicitly
defaulted move constructor is implicitly deleted [-Wdefaulted-function-deleted]
  MOVE_ONLY_NO_DEFAULT_CONSTRUCTOR(LiftoffCompiler);
                                   ^
../../v8/src/wasm/baseline/liftoff-compiler.cc:1834:20: note: move constructor
of 'LiftoffCompiler' is implicitly deleted because field 'asm_' has a deleted
move constructor
  LiftoffAssembler asm_;
                   ^

../../v8/src/wasm/wasm-debug.cc:95:3: warning: explicitly defaulted move
assignment operator is implicitly deleted [-Wdefaulted-function-deleted]
  MOVE_ONLY_NO_DEFAULT_CONSTRUCTOR(InterpreterHandle);
  ^
../../v8/src/wasm/wasm-debug.cc:98:19: note: move assignment operator of
'InterpreterHandle' is implicitly deleted because field 'interpreter_' has a
deleted move assignment operator
  WasmInterpreter interpreter_;
                  ^
../../v8/src/wasm/wasm-interpreter.h:211:35: note: copy assignment operator of
'WasmInterpreter' is implicitly deleted because field 'internals_' is of
const-qualified type 'v8::internal::wasm::WasmInterpreterInternals *const'
  WasmInterpreterInternals* const internals_;
                                  ^

Bug: chromium:890307
Change-Id: Idfc5827f24821212081a006c4329c466c4576bcc
Reviewed-on: https://chromium-review.googlesource.com/c/1256863
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56351}

It was shipped in Chrome 66.

Bug: v8:4958, v8:8255, v8:8238
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I52fb826f4f245bc6484d8f406ecf99bc17d268ee
Reviewed-on: https://chromium-review.googlesource.com/c/1254123Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56350}

The proposal is currently at Stage 3 of the TC39 process.

Repository: https://github.com/tc39/proposal-well-formed-stringify

Bug: v8:7782
Change-Id: Ice2125ffd3dbc5381c81193eb64d460e0d5485cd
Reviewed-on: https://chromium-review.googlesource.com/c/1255728Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56349}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/64ce4b0..3d9873f

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/2ba11d1..2dd9144

Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/95d4c85..0daedf7

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

Change-Id: I4cebb87b89dbd10a350cd6349c72eab428b6df57
Reviewed-on: https://chromium-review.googlesource.com/c/1258125Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#56348}

By moving the block range end to left of closing bracket,
we can avoid ambiguity where an open-ended singleton range
could be both interpreted as inside the parent range, or
next to it.

R=verwaest@chromium.org

Bug: v8:8237
Change-Id: Ibc9412b31efe900b6d8bff0d8fa8c52ddfbf460a
Reviewed-on: https://chromium-review.googlesource.com/1254127Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56347}

The root register is not available in JS-to-Wasm functions, and
this was not reflected in the linkage. Similarily, it is not
available in C-to-Wasm functions.

Change-Id: I2dbfd06ef99d6f9b9940e9489f563441d9ebfabd
Bug: v8:6666
Reviewed-on: https://chromium-review.googlesource.com/1256766
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56346}

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

Change-Id: I7591ccc55405a2fbd258bf28d53cd40a4bddf2c2
Reviewed-on: https://chromium-review.googlesource.com/1255102Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#56344}

Int64AbsWithOverflow should have 2 return value, the 2nd one should
indicate whether it's overflow or not.

This causes a debug failure on s390x.

Change-Id: I2874227751d5874b47e63fed9e8f085f5165a44d
Reviewed-on: https://chromium-review.googlesource.com/1255642Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#56343}

Change-Id: Iaa48cf1b7682aecfcb163e0b30538b9d8bd396db
Bug: v8:6666
Reviewed-on: https://chromium-review.googlesource.com/1256767Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56342}