The respective code was removed in May 2015:
c5eb9573

R=jochen@chromium.org
BUG=v8:6474
NOTRY=true

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I21be194e16b0a10613d62bc38fa10faee082da41
Reviewed-on: https://chromium-review.googlesource.com/530685Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45837}

Variadic template FTW!

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

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

The instanceof cache was initially introduced to speed up

  x instanceof y

where y is always the same constructor and x is always an object with
the same map. With the introduction of ES2015's @@hasInstance and the
Function.prototype[Symbol.hasInstance] handler (which calls into
OrdinaryHasInstance), this already became quite useless. It doesn't seem
to provide any real value (not sure it ever did for real), but it's
getting in the way of some useful refactorings (i.e. sharing logic
between OrdinaryHasInstance and Object.prototype.isPrototypeOf for
example).

So this CL completely removes the leftover bits of the instanceof cache,
including the GC and SetPrototype logic.

BUG=v8:6479,v8:6474
R=jgruber@chromium.org
TBR=ulan@chromium.org

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

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/b8ed7ac..bb21bc0

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

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

Add vpinsrd, vpextrd, vmovd. Supplement pshufd and add vpshufd.
Add Movd and Pshufd macro. Add AVX support to Pextrd.
Fix disassembler to recognize "pinsrd/pextrd xmm,[mem],imm8".

BUG=

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

Follows https://codereview.chromium.org/2931143002/. Sufficient to link
d8 with target_os="fuchsia" in Chrome. No implementations of platform
functions yet, just stubs.

BUG=chromium:731217

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

Sufficient to compile //v8 in Chrome with target_os="fuchsia". Doesn't
link yet, due to missing implementations (primarily VirtualMemory, as
well as a few utility functions).

BUG=chromium:731217
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng

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

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/7e9e29e..b8ed7ac

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

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

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/41581bc..7e9e29e

Rolling v8/buildtools: https://chromium.googlesource.com/chromium/buildtools/+log/31d4daa..b53a03d

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

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

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

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

Minor fix to original CL https://chromium-review.googlesource.com/527156
adding the cmp instr to set the condition code for 32bit.

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

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

It was too early to remove SharedFunctionInfo::kCompilerHintsSize.

TBR=jkummerow@chromium.org

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

Port af76779a

Original Commit Message:

    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=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:4587,v8:5269
LOG=N

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

Define compiler hints bits as bit fields but not as enum.
This eases adding new bit fields to the compiler hints field.

TBR=marja@chromium.org

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

This CL removes most occurences of "WASM" from outputs and comments in
the code. They are replaced either by "WebAssembly" or (especially in
comments) "wasm". These are the spellings officially proposed on
http://webassembly.org/.

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

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Id39fa5e25591678263745a4eab266db546e65983
Reviewed-on: https://chromium-review.googlesource.com/529085Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45824}

BUG=v8:6474

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

Introduce base::make_unique as a replacement for std::make_unique,
introduced in C++14.
Use it in the wasm code base to construct new objects and wrap them in
a unique_ptr, making the code more compact and readable.

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

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

Add kInternalizedNonEmptySeqString and make kInternalizedString = 
kEmptyString | kInternalizedNonEmptySeqString.

BUG=chromium:731495

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

This CL changes the printed wasm locations to use the spec'ed format
(see https://github.com/WebAssembly/design/blob/master/Web.md#developer-facing-display-conventions).

Before: <WASM[<id>]+<offset>
After:  wasm-function[<id>]:<offset>

R=ahaas@chromium.org

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

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

Change-Id: I84be45bab041082cc66b5fdd70a9e799a44facee
Reviewed-on: https://chromium-review.googlesource.com/529207Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45819}

Shape also contains the Key type. Read it through there instead.

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

In some [1] cases where a lexical declaration is not allowed, ASI will
cause a `let` at the end of a line to be interpreted as an
identifier. A recent patch [2] to fix up the error messages from
misplaced `let` usage was a little overzealous in triggering
the error, throwing a SyntaxError in this edge case. This patch
restores the ASI behavior, which is permitted in JSC and
SpiderMonkey as well. Thanks to a test262 test from Andre Bargull
for raising this issue.

[1] https://tc39.github.io/ecma262/#sec-expression-statement
[2] https://codereview.chromium.org/2697193007

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

And in one case just remove it since it is superflous.

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

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

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}