Windows SDK defines `near` and `far` as macro in minwindef.h, so they cannot be
used as variable name if Windows SDK header file is included for Windows build.

Bug: chromium:893460
Change-Id: I5ed1076b965979b8e4e09958c1b6f0a698ec8d4f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1783839Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Tom Tan <Tom.Tan@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#63559}

Implement I64x2 multiply using 32-bit multiplies.

This approach uses two fewer cycles (0.88x) on Cortex-A53 and three fewer cycles (0.86x)
on Cortex-A72, compared to moving to general purpose registers and doing two 64-bit multiplies.

Based on a patch by Zhi An Ng.

Bug: v8:8460
Change-Id: I9c8d3bb77f0d751eec2d85823522558b7f173628
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781696
Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63558}

Reduce number of old-to-new invalidations. MigrateFastToFast,
MigrateFastToSlow and DeleteObjectPropertyFast only need to invalidate
objects in some cases but not in all.

Bug: v8:9454
Change-Id: I901eecb9409c6dfa30cf6b4ee0bdd597862fc229
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781042Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63557}

I removed the padding field because I couldn't see a reason why we would
want to pad to system pointer size. I'm guessing that the intent was to
pad to tagged pointer size, which was once relevant but isn't anymore
since one of the int32 fields got removed.

Bug: v8:8952
Change-Id: Ic191d783efd8d686f6920e6e7ce2d3dacba883c5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1776847Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#63556}

R=mlippautz@chromium.org

Bug: v8:9396
Change-Id: If197687b6208257be18f91b4b172ec41600c21b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784287Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63555}

This reverts commit 352a154e.

Reason for revert: https://crbug.com/999972

Original change's description:
> [compiler] improve inlining heuristics: call frequency per executed bytecodes
> 
> TLDR: Inline less, but more where it matters. ~10% decrease in Turbofan
> compile time including off-thread, while improving Octane scores by ~2%.
> 
> How things used to work:
> 
> There is a flag FLAG_min_inlining_frequency that limits inlining by
> the callsite being sufficiently frequently executed. This call frequency
> was measured relative to invocations of the parent (= the function we
> originally optimize). At the same time, the limit was very low (0.15),
> meaning we mostly relied on the total amount of inlined code
> (FLAG_max_inlined_bytecode_size_cumulative) to limit inlining.
> 
> How things work now:
> 
> Instead of measuring call frequency relative to parent invocations, we
> should have a measure that predicts how often the callsite in question
> will be executed in the future. An obvious attempt at that would be to
> measure how often the callsite was executed in absolute numbers in the
> past. But depending on how fast feedback stabilizes, it can take more
> or less time until we optimize a function. If we just take the absolute
> call frequency up to the point in time when we optimize, we would
> inline more for functions that stabilize slowly, which doesn't make
> sense. So instead, we measure absolute call count per KB of executed
> bytecodes of the parent function.
> Since inlining big functions is more expensive, this threshold is
> additionally scaled linearly with the bytecode-size of the inlinee.
> The resulting formula is:
> call_frequency >
> FLAG_min_inlining_frequency *
>   (bytecode.length() - FLAG_max_inlined_bytecode_size_small) /
>   (FLAG_max_inlined_bytecode_size - FLAG_max_inlined_bytecode_size_small)
> 
> The new threshold is chosen in a way that it effectively limits
> inlining, which allows us to increase
> FLAG_max_inlined_bytecode_size_cumulative without increasing inlining
> in general.
> 
> The reduction in compile time (x64 build) of ~10% was observed in Octane,
> ARES-6, web-tooling-benchmark, and the standalone TypeScript benchmark.
> The hope is that this will reduce CPU-time in real-world situations
> too.
> The Octane improvements come from inlining more in places where it
> matters.
> 
> Bug: v8:6682
> 
> Change-Id: I99baa17dec85b71616a3ab3414d7e055beca39a0
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768366
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63449}

TBR=rmcilroy@chromium.org,neis@chromium.org,jgruber@chromium.org,tebbi@chromium.org,mslekova@chromium.org

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

Bug: v8:6682 chromium:999972
Change-Id: Iffca63d4bef81afa0f66e34d35fb72f3b5baf517
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784281Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63554}

Bug: v8:9463
Change-Id: I4d9d35222597925a289a6c3055ef0ca0aaa43a2f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1775926
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63553}

Graph creation used to handle exception throwing gracefully, but this
seems to never happen, so turned it into a CHECK instead.

Change-Id: I90f8471fe77eb66402fd8abe0d5b15dcffee49bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784286
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63552}

We already do this (if we can't migrate them) when processing the
feedback but it could still happen that we find a deprecated map in the
graph later on.

Bug: chromium:996819, v8:7790
Change-Id: I3b9acc8bc21b5a9812235145b726ba3e53cc8957
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784284Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63551}

This reverts commit 981aafaf.

Reason for revert: Still crashing on Canary.

Original change's description:
> Reland "[ic] In-place Double -> Tagged transitions"
>
> This is a reland of 0736599a.
> This is a reland of 7e1fbe8f.
>
> Original change description:
> > [ic] In-place Double -> Tagged transitions
> >
> > With no more MutableHeapNumber, we can make Double -> Tagged transitions
> > in-place, at the cost of an extra map check when accessing double fields
> > to make sure they are still doubles.
> >
> > Bug: v8:9606
> > Change-Id: I74ff39ed6fba62ee223cd37dfe761f7d73020e1c
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743973
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#63374}
>
> TBR=verwaest@chromium.org, tebbi@chromium.org
>
> Bug: v8:9606
> Change-Id: I2d1b7416064d743582f4983fb868316b7e8a4cf2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1777661
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63499}

TBR=leszeks@chromium.org, verwaest@chromium.org, tebbi@chromium.org

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

Bug: v8:9606
Bug: chromium:997989
Change-Id: Ic95166e67df68e84a524dffd8155121c3ff6aa13
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784283
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63550}

The "address" pointer we pass to {Allocate} and {AllocatePages}
functions is actually just a hint. The actual address of the
reservation is returned by the function.
This CL renames the {address} argument of those functions to {hint} to
make this semantic more clear.

R=mlippautz@chromium.org

Bug: v8:9396
Change-Id: I9ff3785ea4e6f9b7d77f26f224445f3f92e11f22
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784280Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63549}

Instead of checking code flags to decide if the irregexp code object is
an off-heap trampoline, we now directly load the builtin index offset
and treat the code as on-heap if the offset is -1.

In addition the regexp stack now has its own external reference for top
of stack address. This prevents calculating the top of stack address
using the base address and size at every invocation.

Bug: chromium:999993
Change-Id: I23649e8b410a56276f26846b0b12ad29310c3db7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1782565Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Patrick Thier <pthier@google.com>
Cr-Commit-Position: refs/heads/master@{#63548}

I don't know if there is another problem, but this change fixes all
problems in the test case. The fuzzer will eventually tell us if there
is another problem.

R=clemensh@chromium.org

Bug: chromium:1000503
Change-Id: I2f3ca9132e1b9e3f01e9b32604fb39b2272723f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784278
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63547}

This reverts commit bf78435b.

Reason for revert: This CL is not what I wanted to land. I mixed up my local branches.

Original change's description:
> [wasm] Stage wasm-bigint
> 
> The implementation on wasm-bigint has been done, as far as I can tell.
> There are no spec tests yet, only an out-dated copy of the original
> spec tests which don't pass anymore. Therefore I disabled all the tests
> for now and created a tracking bug at https://crbug.com/v8/9673.
> 
> R=​adamk@chromium.org
> 
> Bug: v8:7741, v8:9673
> Change-Id: I015846cc6008ad266402b6835e634723a1a076da
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781050
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63541}

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

Change-Id: I5e8a42ad01200c01446efe4ea50f8ae6fef2c174
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7741, v8:9673
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784279Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63546}

This is a reland of ab089c78, after
making a flaky test more robust.

Original change's description:
> [turbofan] Prepare for moving part of CreateGraph into the background
>
> - Pass Refs, not Handles, to graph builder, and drop bytecode array argument
>   (get it from SFI instead).
> - Add some fields to FeedbackVectorRef that are needed to avoid heap access
>   in BytecodeGraphBuilderPhase.
> - Rename FeedbackVectorRef's SerializeSlots to Serialize, since it's more
>   than just the feedback slots.
> - Rearrange the last steps in PipelineCompilationJob::PrepareJobImpl such
>   that CreateGraph is last.
>
> Bug: v8:7790
> Change-Id: I4b17790d1d74da41ba63ee68e3a33968662fc398
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781682
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63515}

Bug: v8:7790
Change-Id: Ia6f4c1ebd82dea93c14437514d0e25b730523f75
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781694Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63545}

Change-Id: I29a4d20656727e6ec1e1fd052a840bd5aefe3cd4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781052
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63544}

External string resources of length {0} have a {nullptr} data since
https://crrev.com/c/1424861.
This CL fixes allocation of an external one-byte string from such a
resource.

R=ishell@chromium.org

Bug: chromium:995108
Change-Id: Ic8ef507d808583c1b529085d990d705058953f03
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781051Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63543}

Use the position of commas in async arrow expressions to mark the
initializer position of any parameters that might have been set in the
preceding parameter.

This extends https://chromium-review.googlesource.com/c/v8/v8/+/1710671
to async arrow heads.

Bug: v8:8510, chromium:997320
Change-Id: I98e0ac817c7f53fbf1dced98fb6891a386ee7803
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781057Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63542}

The implementation on wasm-bigint has been done, as far as I can tell.
There are no spec tests yet, only an out-dated copy of the original
spec tests which don't pass anymore. Therefore I disabled all the tests
for now and created a tracking bug at https://crbug.com/v8/9673.

R=adamk@chromium.org

Bug: v8:7741, v8:9673
Change-Id: I015846cc6008ad266402b6835e634723a1a076da
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781050
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63541}

Change-Id: I65c1c5a75cde738f8fce33d2230fd12338f55154
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1783000Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63540}

This CL adds an overloaded function PerfJitLogger::LogWriteDebugInfo
for writing JIT_DEBUG_INFO record into jitdump file. With this CL,
perf-annotate can display profiling information of JITted code with
the corresponding source code interleaved.

Change-Id: Ie1271e08b69712c81129335825467d83674d7938
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1672531Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Zhiguo Zhou <zhiguo.zhou@intel.com>
Cr-Commit-Position: refs/heads/master@{#63539}

AllocatePages (used to allocate the embedded blob's backing store
during mksnapshot) has allocation address, size, and alignment
parameters. Both address and size are expected to be aligned, but we
were only aligning size properly. This CL also aligns the address (and
adds a bunch of comments as well).

Bug: v8:9677
Change-Id: Ia739682236c74278bcaf1c9b7c9c4b3e0b0c5582
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784277
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63538}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/4fa36b1..693faed

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/5198ea1..e7c719c

Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/355e97e..f38bc17

TBR=machenbach@chromium.org,tmrts@chromium.org

Change-Id: I07b2661ff208bf920cc751ebea258c02a3e112b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1783170Reviewed-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@{#63537}

This reverts commit 8b89a7c3.

Reason for revert: GC Stress tests timing out.
See https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/24272

Original change's description:
> Update GetIterator bytecode to load and call object[Symbol.iterator]
> 
> The functionality of the GetIterator bytecode introduced previously is
> now extended from loading the @@iterator property to calling the property
> as well. This change basically absorbs the functionality of additional
> two bytecodes - Star, CallProperty0 in the GetIterator bytecode.
> Importantly, this change handles the cases of eager and lazy deoptimization
> in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and
> eager deopt of the CallProperty0 bytecode, using the continuation builtins.
> This mechanism can work as a template for the future bytecode that require
> handling such inter-bytecode deopt scenario. The tests evaluating the eager
> and lazy deopt scenarios are also included.
> 
> Bug: v8:9489
> Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313
> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63528}

TBR=rmcilroy@chromium.org,neis@chromium.org,leszeks@chromium.org,tebbi@chromium.org,swapnilgaikwad@google.com

Change-Id: I9ae475f71275f71f1b9e60b8bf0578e21ce2704b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9489
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1783736Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63536}

This reverts commit 93063ade.

Reason for revert: Clusterfuzz found issue.

Original change's description:
> [heap] Remove size from invalidated slots
> 
> Slots are always valid inside an invalidated area when outside the
> respective object's current size. This allows us to remove the size
> from the InvalidatedSlots data structure.
> 
> This change was enabled by https://crrev.com/c/1771793.
> 
> Bug: v8:9454
> Change-Id: I2b5a7234d47227cb6ad8d67de20e9b5a2028ae83
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773242
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63510}

TBR=ulan@chromium.org,sigurds@chromium.org,tebbi@chromium.org,dinfuehr@chromium.org

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

Bug: v8:9454
Change-Id: I7daf96cf50aaedd4dbdab48fd550182df94e54bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1783106Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63535}

Port 85e2dbb3

R=zhin@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N

Change-Id: I2edef96f0323a5fd480e3dab02b80f1ab401efd8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1780339Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#63534}

Bug: v8:8976
Change-Id: I6ed0a8d4b64a15b071d9b59121e08db9f6679694
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1779331
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63533}

Bug: v8:8460
Change-Id: I529310a35b74964cb034b4c757981c7ec70f1d19
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1765442Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63532}

Bug: v8:9666,v8:3770
Change-Id: I06ab353e9e3b492e73f692861280c0f278759e98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1776843Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63531}

Bug: chromium:999853
Change-Id: I5ff8a1d742b871487bc0b0235f4f24d0aaf5c20e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1782176
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63530}

memcpy doesn't like being called with dest=nullptr and size=0.

Change-Id: Ie01991834a867991ff51287cbe43d22f636b800e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781695Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63529}

The functionality of the GetIterator bytecode introduced previously is
now extended from loading the @@iterator property to calling the property
as well. This change basically absorbs the functionality of additional
two bytecodes - Star, CallProperty0 in the GetIterator bytecode.
Importantly, this change handles the cases of eager and lazy deoptimization
in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and
eager deopt of the CallProperty0 bytecode, using the continuation builtins.
This mechanism can work as a template for the future bytecode that require
handling such inter-bytecode deopt scenario. The tests evaluating the eager
and lazy deopt scenarios are also included.

Bug: v8:9489
Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313
Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63528}

This CL makes ThreadManager::InitThread *the* place that's responsible
for initializing metadata for a new thread, and ensures that all new
threads actually go through there. This was previously not the case,
and e.g. test-lockers/LockerUnlocker exposed a case where some threads
were trying to use another thread's simulator instance because the
ThreadLocalTop on the Isolate was in inconsistent state.

Change-Id: I302c643f420457f6ba73897fd45eb87969e1331c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781688
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63527}

to avoid undefined behavior on signed integer overflow.

Change-Id: Ib55b427723a81dddc26f3ce4b2b3b8cc69c9c017
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1782166
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63526}

This is a reland of d82600ec

Added missing builtin serializations that were breaking Clusterfuzz,
layout tests and Speedometer.

Original change's description:
> [turbofan] Serialize missing objects
>
> Added a few objects to the standard objects list, as well as specific
> builtins when the corresponding runtime calls are detected in the
> serializer. Now JSHeapCopyReducer is needed only when concurrent
> inlining is disabled.
>
> Bug: v8:7790
> Change-Id: I91d933611b0352df8ede4fded665f13669591fef
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781053
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Maya Lekova <mslekova@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63509}

Bug: v8:7790, chromium:1000136
Change-Id: I4775014bfe8100fb76f60e4088f1bdf2a8da64a2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781681
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63525}

NativeContext will soon outgrow the limits of the fixed sized map.
This CL simply moves NativeContext back to the variable sized map.

Bug: v8:9463
Change-Id: I477dc5f19ed22b5b2b8d3415daad9d87e785bdcb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1774185Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63524}

This reverts commit 2869d9de.

Reason for revert: Failing on V8 Arm - debug

Original change's description:
> [turbofan,arm64] Add float loads poisoning.
> 
> Also extend load poisoning testing for arm and arm64.
> 
> This is a port of I1ef202296744a39054366f2bc424d6952c3bbe9d,
> originally introduced for arm.
> 
> Change-Id: I7d317bba6be633dd1e563daa7231d3c5e930f8e4
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1691032
> Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63519}

TBR=rmcilroy@chromium.org,mvstanton@chromium.org,neis@chromium.org,tebbi@chromium.org,martyn.capewell@arm.com,artem.serov@arm.com

Change-Id: I60ae552f98ae843d4fecbe163d60580a9f1a7068
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1782163Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
Cr-Commit-Position: refs/heads/master@{#63523}

The important bit is using MachineType::TaggedSigned instead of AnyTagged
in CSA. Everything else, it's just the result of adding types to variables.

SloppyTNode-ify LoadAndUntagToWord32ObjectField.

Both LoadAndUntagSmi and StoreAndTagSmi were only used once, and their
names were not clear. Inline those where they were used.

TNodify:
* ReloadBytecodeOffset
* LoadAndUntagRegister
* GetInterpretedFramePointer
* Advance (the three variants)
* SaveBytecodeOffset
* BytecodeOffset

Type variables:
* interpreted_frame_pointer_
* bytecode_offset_

Create macros:
* TYPED_VARIABLE_CONSTRUCTOR
* TVARIABLE_CONSTRUCTOR
which are similar to their non-typed counterparts.

Bug: v8:7703, v8:6949
Change-Id: I776e3fe16ca642f868bb635b8bcd5b8b78ca6fea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758308Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63522}

R=clemensh@chromium.org
TEST=mjsunit/wasm/asm-wasm-math-intrinsic
BUG=v8:8505

Change-Id: I883c9ad174f7fda5ec5dd24e71ca674de51239b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1782160Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63521}

The regexp species protector was recently moved from the isolate onto
the native context to avoid cross-context pollution of the regexp fast
path state.

The implementation was incomplete. We unconditionally used the isolate's
current native context, but it is possible for the object we are looking
at to come from a different context (= its creation context).

The fix is two-fold. 1. when speed is not too important (e.g. when
invalidating the protector), grab the creation context off the object.
2. in the regexp fast path check, just document how our current solution
is sufficient: although we may initially look at the wrong protector
cell, we'd later bail out when comparing the object's map against the
initial regexp map (stored on the current native context).

Bug: v8:9463
Change-Id: I653732b573f2dd456b3c6b723653dcacf9ead591
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1776078
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63520}