Change-Id: I2d8f4defd465b2f9838ed002add088da5b6739ef
Reviewed-on: https://chromium-review.googlesource.com/528197Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45815}

Bug: v8:6474
Also-By: cbruni@chromium.org
Change-Id: I1aefa1156b89a7f8ffafe27e58cacbfecc9a1d02
Reviewed-on: https://chromium-review.googlesource.com/528885Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45814}

This reduces confusion with GC write barrier. The word "barrier" is
reserved for GC write barrier and "fence" for memory ordering fence.

BUG=v8:6474

Change-Id: Ic4352f04430eaca742b72db1580ee0a42a1ffefb
Reviewed-on: https://chromium-review.googlesource.com/528103Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45813}

The wasm-code fuzzer used different parameters for the interpreter and
the generated code due to a typo. This typo is fixed by this CL.

R=clemensh@chromium.org

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

Also, as this is hard to track down, always DCHECK position after ReadBlock().

Change-Id: Ie32c3a311dd8df91f651b6d82ccacc7c95e6fde0
Reviewed-on: https://chromium-review.googlesource.com/528196
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45811}

base::Optional is a replacement for std::optional, until we switch to
C++17 and can use std::optional directly.
The implementation is copied from chromium's base::Optional, but put in
the {v8::base} namespace instead of just {base}. Also, the
specialization of std::hash for base::Optional is omitted, since it's
disallowed in the style guide.

A first use in the AsmJsParser is introduced, if that one sticks, I
will refactor more uses of std::unique_ptr to use base::Optional
instead, avoiding the heap allocation.

R=mstarzinger@chromium.org
BUG=v8:6474

Change-Id: I019599d4bf9ff0105bf592dfb96d6050feba18ae
Reviewed-on: https://chromium-review.googlesource.com/528884
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45810}

ExpressionClassifier was used just for transmitting information back and forth
to DeclareFormalParameters.

As a bonus, we now do the Scope::IsDeclaredParameter check only when we're going
to use the information it produces.

BUG=v8:6092,v8:6474

Change-Id: Ib5ac6a779705caa74e933e1c6f03eaaf0f49bf05
Reviewed-on: https://chromium-review.googlesource.com/455836
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45809}

All the bytecode handlers were added a one test, so we would get a
total on all of the bytecode handler benchmarks. It is not a good
indicator when we total unrelated benchmarks. So added more categories
to group only related benchmarks together. This also makes it easier
to look at the results.

Bug: chromium:730628
Change-Id: I1c5858f40c1ce584c4b7bd833a7f3c52a43d07c6
Reviewed-on: https://chromium-review.googlesource.com/527436
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45808}

The mips/mips64 port of http://crrev.com/2909893002. Original commit message:

DebugInfo was very closely tied to break point support:
* It contained only information relevant to break points.
* It was created and freed by break point implementation.
* Existence of a DebugInfo on the shared function info implied existence of
  break points.

This CL is a step towards making DebugInfo usable by other debugging
functionality such as block coverage by decoupling it from break point support,
which is now only one kind of information stored on the DebugInfo object.

BUG=v8:6000

Change-Id: Ia770ff3c048022652d8abbe30d372fde5cb452a4
Reviewed-on: https://chromium-review.googlesource.com/528112Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45807}

This makes popping from the marking deque safe for concurrent marking.

BUG=chromium:694255

Change-Id: I3edf8ece3d3c3dd8f045b3ea2f8196b322a56a54
Reviewed-on: https://chromium-review.googlesource.com/527154
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45806}

In some codes flushing the registers was costly: we processed each
register whereas all the registers alone in their equivalence class need
not to be processed. We now overapproximate easily which classes are of
size 2 so as to save many iterations in the Flush() loop in some cases.

Bug: v8:6432
Change-Id: I945e151736e8a515263ac76312127d930fd20d74
Reviewed-on: https://chromium-review.googlesource.com/525795
Commit-Queue: Alexandre Talon <alexandret@google.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45805}

Use convenient macros for accessing bit fields.

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

This removes the ability of the compilation pipeline to invoke the
Crankshaft optimizing compiler for JavaScript functions. Note that in
this state Crankshaft can still be used to compile code stubs.

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

Change-Id: I0bec7c8ec7c705c13257df43796403a228ea631c
Reviewed-on: https://chromium-review.googlesource.com/527443Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45803}

In sloppy mode, allow multiply labelled function declarations, such as

a: b: function c() {}

Such a form is allowed by the specification, as well as ChakraCore,
SpiderMonkey and JSC (though ChakraCore because it doesn't enforce
any lexical label restrictions.)

Thanks to Andre Bargull for adding the test262 test which caught the bug.

Change-Id: I2d3f172830c2e63252f00afa03177a7d17d79a27
Reviewed-on: https://chromium-review.googlesource.com/527639Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45802}

The JSCreateClosure operator was not marked as Eliminatable, esp. it
wasn't marked as NoWrite (read: no JavaScript observable side-effect),
which lead to a weird performance cliff with the new Array builtin
inlining. For example

  a.forEach(c => c);

was not inlined, whereas

  const f = c => c;
  a.forEach(f);

was properly inlined, despite not causing any trouble for TurboFan in
general. The reason was that the JSCreateClosure for the arrow function
was marked as "can cause potential side effect", which it cannot. This
fixes the operator to be properly marked as Eliminatable, thus removing
this performance cliff.

BUG=v8:1956,v8:6475
R=danno@chromium.org

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

Both Ignition and TurboFan have been enabled by default for a while.
This just disentangles the implication between those two flags and sets
the --ignition individually. They can now be controlled individually.

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

Change-Id: I08eca85120160efa5868b5ca36d1613964ed82eb
Reviewed-on: https://chromium-review.googlesource.com/527637Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45800}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/9d6666d..41581bc

Rolling v8/tools/swarming_client: https://chromium.googlesource.com/external/swarming.client/+log/5c4eed8..af6b06c

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

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

Port 90c3a2d5

Original Commit Message:

    This CL contains a few pieces:

    - A new mechanism to create "BuiltinContinuation" checkpoints in TurboFan
      graphs, which--when triggered--swizzle the values in the the FrameState to be
      parameters to a typically TF-generated builtin that resumes execution to finish
      the slow-case functionality.
    - Continuation builtins that have special handling in the deoptimizer and their own
      new frame type to ensure that the values they need to begin executing can be stashed
      away and restored immediately before the builtin is called via a trampoline that runs
      when the continuation builtin's frame execution resumes.
    - An implementation of Array.prototype.forEach in TurboFan that can be used to
      inline it. The inlined forEach implementation uses the checkpoints mechanism
      described above to deopt in the middle of the forEach in the cases that optimization
      invariants are violated. There is a slightly different continuation stub for each
      deopt point in the forEach implementation to ensure the correct side-effects, i.e.
      that the deopt of the builtin isn't programmatically observable.

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

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

Revert of [heap] Use larger marking steps during external allocation pressure (patchset #4 id:60001 of https://codereview.chromium.org/2927553003/ )

Reason for revert:
Blocks the roll. Fails some layout tests:
https://build.chromium.org/p/tryserver.v8/builders/v8_linux_blink_rel/builds/21757

STDERR: # Fatal error in ../../v8/src/heap/heap.cc, line 957
STDERR: # Check failed: 1.0 <= pressure (1 vs. -0.00503761).

Original issue's description:
> [heap] Use larger marking steps during external allocation pressure
>
> BUG=chromium:626082, chromium:728228
>
> Review-Url: https://codereview.chromium.org/2927553003
> Cr-Commit-Position: refs/heads/master@{#45784}
> Committed: https://chromium.googlesource.com/v8/v8/+/8d75644fc0ce1cee5d6eca42006f4c4aa89e9b86

TBR=ulan@chromium.org,hpayer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:626082, chromium:728228

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

Port d3371c23

Original Commit Message:

    DebugInfo was very closely tied to break point support:
    * It contained only information relevant to break points.
    * It was created and freed by break point implementation.
    * Existence of a DebugInfo on the shared function info implied existence of
      break points.

    This CL is a step towards making DebugInfo usable by other debugging
    functionality such as block coverage by decoupling it from break point support,
    which is now only one kind of information stored on the DebugInfo object.

R=jgruber@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:6000
LOG=N

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

- Eliminates b1x4, b1x8, and b1x16 as distinct WASM types.
- All vector comparisons return v128 type.
- Eliminates b1xN and, or, xor, not.
- Selects take a v128 mask vector and are now bit-wise.
- Adds a new test for Select, where mask is non-canonical (not 0's and -1's).

LOG=N
BUG=v8:6020

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

This splits the monolithic Apply builtin into several smaller builtins,
namely CallVargargs and ConstructVarargs, which accept a length and a
FixedArray of elements and deal with the actual stack manipulation, and
CallWithArrayLike / ConstructWithArrayLike that deal with getting the
elements from the receiver (for Function.prototype.apply, Reflect.apply
and Reflect.construct), which can now be written using the CSA.

The idea is that these builtins can be reused by TurboFan directly in
the future when we optimize apply better, and that we can also reuse the
core logic in the handling of spread calls/constructs.

R=petermarshall@chromium.org
BUG=v8:4587,v8:5269

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

Port 659e8f7b

Original Commit Message:

    Instead of allocating and embedding certain heap numbers into the code
    during code assembly, emit dummies but record the allocation requests.
    Later then, in Assembler::GetCode, allocate the heap numbers and patch
    the code by replacing the dummies with the actual objects. The
    RelocInfos for the embedded objects are already recorded correctly when
    emitting the dummies.

R=neis@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, bjaideep@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:6048
LOG=N

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

concurrent sweeping is disabled, which is not correct.

MemoryAllocator: :CanFreeMemoryChunk returns true for the case when
Change-Id: I560bac0275473445b52fba28b5e647b54f523a3a
Reviewed-on: https://chromium-review.googlesource.com/528081Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45792}

This CL takes advantage of the fact that StatsCounter is now local to
the Counters class. This includes:

1) Method StatsTable::SetCreateHistogramFunction() was only called in
one spot (in api.cc), which also called Counters::ResetHistograms()
and Counters::InitializeHistorgram(). InitializeHistogram can be
folded into Histogram.Reset().

2) Since Histogram::Reset() now regenerats the histogram, we no longer
need the field lookup_done_. Therefore there is no longer a race
between updating ptr_ and lookup_done_, making the Histogram class
thread safe.

3) Made the constructors of several classes private (except for class
Counters), minimizing the scope that they are used. When the couldn't
be moved, add comment that they were public only for test cases.

4) Removed the need for a mutex lock on StatsCounter::Reset(), since
it is now guaranteed to only be called when
StatsTable::SetCounterFunction() is called.

BUG=v8:6361
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng

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

[builtins] Make sure to perform ToPrimitive(key, hint string) in hasOwnProperty even if the receiver is a smi.

Bug: chromium:707580
Change-Id: I38f8740ac0df5d5e4e99808e4fa20bae88a23a11
Reviewed-on: https://chromium-review.googlesource.com/528077Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45790}

Both TurboFan and ThinStrings have been enabled by default for a while.
This just disentangles the implication between those two flags and sets
the --thin-strings individually. There is no technical reason for the
implication.

R=jkummerow@chromium.org

Change-Id: I26e5357ffaf953de897c76d6edb8ac640bbeafd0
Reviewed-on: https://chromium-review.googlesource.com/528076Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45789}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/4161431..9d6666d

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

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

Bug: v8:5717
Change-Id: I03579764656aa743bbc9bbf08e6affecd626d73d
Reviewed-on: https://chromium-review.googlesource.com/527338Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45787}

Add the ability for the typer to track whether a string could be the empty
string. This is needed for typed lowering of JSStringConcat since we can't
create cons string chain with the empty string in arbitrary positions.

The ToPrimitiveToString bytecode handler is modified to collect feedback on
whether it has ever seen the empty string, which is used by
SpeculativeToPrimitiveToString to ensure that the output is non-empty (or
depot) which will subsiquently be used to enable inline cons-string creation
for the JSStringConcat operator in typed lowering in a subsiquent CL.

BUG=v8:6243

Change-Id: I41b99b59798993f756aada8cff90fb137d65ea52
Reviewed-on: https://chromium-review.googlesource.com/522122
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45786}

The variant in question was intended to test Crankshaft, which is being
deprecated. Note that the variants 'nooptimization' and 'fullcode' still
test configuration where TurboFan is not active.

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

Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I587c3eee7ba511dfc270aab66b546d2532bc635f
Reviewed-on: https://chromium-review.googlesource.com/528133Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45785}

BUG=chromium:626082, chromium:728228

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

ThrowIfHole bytecodes were handled by introducing deopt points to check
for a hole. To avoid deopt loops a hole check protector was used to
generate control flow if there was a deopt due to a hole. However, the
normal control flow version should be as fast as the deopt version
in general. The deopt version could potentially consume less compile time
but it may not be worth the complexity added. Hence simplifying it to
only construct the control flow.

Bug: v8:6383
Change-Id: Icace11f7a6e21e64e1cebd104496e3f559bc85f7
Reviewed-on: https://chromium-review.googlesource.com/525573Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45783}

This removes the last remaining dual implications between sets of flags.
Support for this was originally added to support multiple subsequent
calls to {SetFlagFromString} switching a set of flags on and off. Now
that Chrome no longer relies on this behavior we can remove support for
this entirely.

Original CL: https://crrev.com/f774d8c56f00de92614886fc4cb541411eff7aa1

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

Change-Id: I5f9db8457c562c0b434ea7d6eca9941c76fe7d19
Reviewed-on: https://chromium-review.googlesource.com/527174Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45782}

Don't treat new prototypes differently depending on how they become a
prototype. This is work towards always keeping prototypes in slow-mode.


Bug: v8:6471
Change-Id: I62de1018e21d91fda3a5da044615f32c718910b1
Reviewed-on: https://chromium-review.googlesource.com/526596Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45781}

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

This adds block coverage support for simple iteration. For-of and
for-in loops are not yet covered, and we don't yet keep execution counts
for init, cond, and next statements.

BUG=v8:6000

Change-Id: I30b468a2c93f0bb60e857b6632be92920f6857e0
Reviewed-on: https://chromium-review.googlesource.com/527113
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45779}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/d122cd7..4161431

Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/3919ea6..32bdd96

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

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

Array buffers can now have an allocation that is larger than the actual
buffer, such as when WebAssembly guard regions are enabled. Embedders
need to know the actual allocation start and length when externalizing
a buffer so they can deallocate it properly.

Bug: chromium:720302, v8:5277
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ifc184fdd59d77af01c07a64d2c0229ca859a01b0
Reviewed-on: https://chromium-review.googlesource.com/523271
Commit-Queue: Eric Holk <eholk@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45777}

Calling `read(filename, 'binary')` should return an ArrayBuffer like
SpiderMonkey does. It is possible to call `readbuffer` instead, but that
function is not available in the SpiderMonkey JS shell.

BUG=v8:6464
R=bradnelson@chromium.org

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