Revert of [simd.js] Update to spec version 0.8.2. (patchset #11 id:200001 of https://codereview.chromium.org/1294513004/ )

Reason for revert:
Fails tests:
http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20deadcode/builds/5073/steps/steps/logs/stdio

Original issue's description:
> [simd.js] Update to spec version 0.8.2.
>
> Adds Uint32x4, Uint16x8, and Uint8x16 types.
> Adds all functions in the current spec, except for loads and stores.
>
> LOG=Y
> BUG=v8:4124
>
> Committed: https://crrev.com/4be6d37fd1ad0a6e0ea37da8863ae5169c2b89ba
> Cr-Commit-Position: refs/heads/master@{#30322}

TBR=littledan@chromium.org,bbudge@google.com,bmeurer@chromium.org,hpayer@chromium.org,bbudge@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4124

Review URL: https://codereview.chromium.org/1309513005

Cr-Commit-Position: refs/heads/master@{#30323}

Adds Uint32x4, Uint16x8, and Uint8x16 types.
Adds all functions in the current spec, except for loads and stores.

LOG=Y
BUG=v8:4124

Review URL: https://codereview.chromium.org/1294513004

Cr-Commit-Position: refs/heads/master@{#30322}

These two test cases introduced by 8525136b require that the double register is >=2.
But currently on x87 turbofan implementation only 1 double register is supported.

BUG=

Review URL: https://codereview.chromium.org/1308763003

Cr-Commit-Position: refs/heads/master@{#30321}

R=bmeurer@chromium.org

Review URL: https://codereview.chromium.org/1306023002

Cr-Commit-Position: refs/heads/master@{#30320}

R=mstarzinger@chromium.org

Review URL: https://codereview.chromium.org/1307963002

Cr-Commit-Position: refs/heads/master@{#30319}

Revert of Parse arrow functions at proper precedence level (patchset #2 id:60001 of https://codereview.chromium.org/1286383005/ )

Reason for revert:
Breaks layout test. Please change test expectation on blink first.

--- /mnt/data/b/build/slave/V8-Blink_Linux_64/build/layout-test-results/inspector/sources/debugger-pause/debugger-pause-in-internal-expected.txt
+++ /mnt/data/b/build/slave/V8-Blink_Linux_64/build/layout-test-results/inspector/sources/debugger-pause/debugger-pause-in-internal-actual.txt
@@ -1,4 +1,4 @@
-CONSOLE ERROR: line 9: Uncaught SyntaxError: Expected () to start arrow function, but got '}' instead of '=>'
+CONSOLE ERROR: line 9: Uncaught SyntaxError: Unexpected token )
 Tests that pause on exception in internal script does not crash.

 Script source was shown.

Original issue's description:
> Parse arrow functions at proper precedence level
>
> BUG=v8:4211
> LOG=Y
> R=rossberg@chromium.org
>
> Committed: https://crrev.com/9271b0ccf9ddb217deb1f0b9ef9b59b64dc40214
> Cr-Commit-Position: refs/heads/master@{#30298}

TBR=rossberg@chromium.org,mstarzinger@chromium.org,fennyfanny655@gmail.com,machenbach@chromium.org,wingo@igalia.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4211

Review URL: https://codereview.chromium.org/1315503002

Cr-Commit-Position: refs/heads/master@{#30318}

R=titzer@chromium.org

Review URL: https://codereview.chromium.org/1309883002

Cr-Commit-Position: refs/heads/master@{#30317}

Revert of Add a separate scope for switch (patchset #7 id:120001 of https://codereview.chromium.org/1293283002/ )

Reason for revert:
Breaks cctest/test-cpu-profiler/SourceLocation on nosnap

Original issue's description:
> Add a separate scope for switch
>
> The ES2015 specification for switch statements 13.12.11 specifies that
> they get their own lexical scope. This patch introduces such a scope
> through a complex desugaring in terms of blocks, done so that Crankshaft
> does not have to be updated to support multiple constructs providing
> scopes.
>
> BUG=v8:4377
> LOG=Y
> R=adamk
>
> Committed: https://crrev.com/9edbc1f21eb1050cabbe3b8bc9aebf89ada7ebd7
> Cr-Commit-Position: refs/heads/master@{#30314}

TBR=adamk@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4377

Review URL: https://codereview.chromium.org/1309043004

Cr-Commit-Position: refs/heads/master@{#30316}

The parser has special behavior with respect to the bindings
of inner functions in sloppy mode which are not at the top
level of scopes. This behavior should be turned off when the
--harmony-sloppy-function flag is set, as lexical scoping
rules are used instead. Previously, the incorrect flag
--harmony-sloppy was used, resulting in a crashing bug.

BUG=chromium:520029
LOG=Y
R=adamk

Review URL: https://codereview.chromium.org/1303033003

Cr-Commit-Position: refs/heads/master@{#30315}

The ES2015 specification for switch statements 13.12.11 specifies that
they get their own lexical scope. This patch introduces such a scope
through a complex desugaring in terms of blocks, done so that Crankshaft
does not have to be updated to support multiple constructs providing
scopes.

BUG=v8:4377
LOG=Y
R=adamk

Review URL: https://codereview.chromium.org/1293283002

Cr-Commit-Position: refs/heads/master@{#30314}

While the class Type objects the AstTyper generates should be
allocated to zone memory, there's no particular reason
the typer object itself needs to be.

BUG=None
TEST=None
R=rossberg@chromium.org,titzer@chromium.org
LOG=N

Review URL: https://codereview.chromium.org/1303843003

Cr-Commit-Position: refs/heads/master@{#30313}

R=titzer@chromium.org

Review URL: https://codereview.chromium.org/1310603002

Cr-Commit-Position: refs/heads/master@{#30312}

FutexEmulation::Wait can potentially block forever on a condition variable. We
want to allow this to be interrupted (for a debugger, or to terminate the
thread, for example).

The previous implementation would periodically wake up the waiter to check for
interrupts. This CL modifies the StackGuard so it wakes the blocked futex if
the thread should be interrupted.

BUG=chromium:497295
R=jarin@chromium.org
LOG=n

Review URL: https://codereview.chromium.org/1230303005

Cr-Commit-Position: refs/heads/master@{#30311}

Revert of Concurrently unmap free pages. (patchset #4 id:60001 of https://codereview.chromium.org/1303263002/ )

Reason for revert:
Several tests on V8 Linux64 TSAN bot are broken, due to data races between allocation & GC.

A bisect points to this CL, and the CL description sounds pertinent to the observed breakage.

Original issue's description:
> Concurrently unmap free pages.
>
> BUG=
>
> Committed: https://crrev.com/d1aeb45d96123d47023066b244c0f450fbe57d2d
> Cr-Commit-Position: refs/heads/master@{#30306}

TBR=mlippautz@chromium.org,hpayer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

Review URL: https://codereview.chromium.org/1306213002

Cr-Commit-Position: refs/heads/master@{#30310}

R=titzer@chromium.org

Review URL: https://codereview.chromium.org/1309813002

Cr-Commit-Position: refs/heads/master@{#30309}

R=titzer@chromium.org

Review URL: https://codereview.chromium.org/1304053004

Cr-Commit-Position: refs/heads/master@{#30308}

Calls should have control and effect inputs, which were previously missing
for RawMachineAssembler call operations. Add control and effect edges to
graph()->start().

BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1283193007

Cr-Commit-Position: refs/heads/master@{#30307}

BUG=

Review URL: https://codereview.chromium.org/1303263002

Cr-Commit-Position: refs/heads/master@{#30306}

R=cbruni@chromium.org

Review URL: https://codereview.chromium.org/1309673003

Cr-Commit-Position: refs/heads/master@{#30305}

R=mlippautz@chromium.org

Review URL: https://codereview.chromium.org/1309733002

Cr-Commit-Position: refs/heads/master@{#30304}

BUG=

Review URL: https://codereview.chromium.org/1301963002

Cr-Commit-Position: refs/heads/master@{#30303}

BUG=
TBR=vogelheim@chromium.org,yangguo@chromium.org
NOTRY=true

Review URL: https://codereview.chromium.org/1304203002 .

Cr-Commit-Position: refs/heads/master@{#30302}

BUG=

Review URL: https://codereview.chromium.org/1293283003

Cr-Commit-Position: refs/heads/master@{#30301}

R=yangguo@chromium.org,hpayer@chromium.org

Review URL: https://codereview.chromium.org/1306053003

Cr-Commit-Position: refs/heads/master@{#30300}

BUG=

Review URL: https://codereview.chromium.org/1296713007

Cr-Commit-Position: refs/heads/master@{#30299}

BUG=v8:4211
LOG=Y
R=rossberg@chromium.org

Review URL: https://codereview.chromium.org/1286383005

Cr-Commit-Position: refs/heads/master@{#30298}

port cd351559 (r30284).

original commit message:

BUG=

Review URL: https://codereview.chromium.org/1303223002

Cr-Commit-Position: refs/heads/master@{#30297}

port fe432e1a (r30250).

original commit message:

BUG=

Review URL: https://codereview.chromium.org/1303973004

Cr-Commit-Position: refs/heads/master@{#30296}

This CL is a nightmare! For the utterly irrelevant edge case of a sloppy function with non-simple parameters and a call to direct eval, like here,

  let x = 1;
  function f(g = () => x) {
    var y
    eval("var x = 2")
    return g() + x  // f() = 3
  }

we have to do all of the following, on top of the declaration block ("varblock") contexts we already introduce around the body:

- Introduce the ability for varblock contexts to have both a ScopeInfo and an extension object (e.g., the body varblock in the example will contain both a static var y and a dynamic var x). No other scope needs that. Since there are no context slots left, a special new struct is introduced that pairs up scope info and extension object.

- When declaring lookup slots in the runtime, this new struct is allocated in the case where an extension object has to be added to a block scope (at which point the block's extension slot still contains a plain ScopeInfo).

- While at it, introduce some abstraction to access context extension slots in a more controlled manner, in order to keep special-casing to a minimum.

- Make sure that even empty varblock contexts do not get optimised away when they contain a sloppy eval, so that they can host the potential extension object.

- Extend dynamic search for declaration contexts (used by sloppy direct eval) to recognize varblock contexts.

- In the parser, if a function has a sloppy direct eval, introduce an additional varblock scope around each non-simple (desugared) parameter, as required by the spec to contain possible dynamic var bindings.

- In the pattern rewriter, add the ability to hoist the named variables the pattern declares to an outer scope. That is required because the actual destructuring has to be evaluated inside the protecting varblock scope, but the bindings that the desugaring introduces are in the outer scope.

- ScopeInfos need to save the information whether a block is a varblock, to make sloppy eval calls work correctly that deserialise them as part of the scope chain.

- Add the ability to materialize block scopes with extension objects in the debugger. Likewise, enable setting extension variables in block scopes via the debugger interface.

- While at it, refactor and unify some respective code in the debugger.

Sorry, this CL is large. I could try to split it up, but everything is rather entangled.

@mstarzinger: Please review the changes to contexts.
@yangguo: Please have a look at the debugger stuff.

R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org
BUG=v8:811,v8:2160
LOG=N

Review URL: https://codereview.chromium.org/1292753007

Cr-Commit-Position: refs/heads/master@{#30295}

- Introduce a proper bit for SIMD primitive values.
- Introduce constructors for individual SIMD types. These are currently just classes, which seems good enough for now, given that we always have exactly one global map per SIMD type.

The only problem with using class types for SIMD is that a SIMD constant won't be a subtype of its specific type, only of the general SIMD type. But until we actually introduce SIMD constants into the compiler that shouldn't matter.

R=jarin@chromium.org
BUG=

Review URL: https://codereview.chromium.org/1303863002

Cr-Commit-Position: refs/heads/master@{#30294}

port d0bacc61 (r30235).

original commit message:

BUG=

Review URL: https://codereview.chromium.org/1286123008

Cr-Commit-Position: refs/heads/master@{#30293}

port cbbaf9ea (r30224).

original commit message:

    [turbofan] Unify referencing of stack slots

    Previously, it was not possible to specify StackSlotOperands for all
    slots in both the caller and callee stacks. Specifically, the region
    of the callee's stack including the saved return address, frame
    pointer, function pointer and context pointer could not be addressed
    by the register allocator/gap resolver.

    In preparation for better tail call support, which will use the gap
    resolver to reconcile outgoing parameters, this change makes it
    possible to address all slots on the stack, because slots in the
    previously inaccessible dead zone may become parameter slots for
    outgoing tail calls. All caller stack slots are accessible as they
    were before, with slot -1 corresponding to the last stack
    parameter. Stack slot indices >= 0 access the callee stack, with slot
    0 corresponding to the callee's saved return address, 1 corresponding
    to the saved frame pointer, 2 corresponding to the current function
    context, 3 corresponding to the frame marker/JSFunction, and slots 4
    and above corresponding to spill slots.

    The following changes were specifically     needed:

    * Frame     has been changed to explicitly manage three areas of the
      callee frame, the fixed header, the spill slot area, and the
      callee-saved register area.
    * Conversions from stack slot indices to fp offsets all now go through
      a common bottleneck: OptimizedFrame::StackSlotOffsetRelativeToFp
    * The generation of deoptimization translation tables has been changed
      to support the new stack slot indexing scheme. Crankshaft, which
      doesn't support the new slot numbering in its register allocator,
      must adapt the indexes when creating translation tables.
    * Callee-saved parameters are now kept below spill slots, not above,
      to support saving only the optimal set of used registers, which is
      only known after register allocation is finished and spill slots
      have been allocated.

BUG=

Review URL: https://codereview.chromium.org/1293103003

Cr-Commit-Position: refs/heads/master@{#30292}

R=bmeurer@chromium.org

Review URL: https://codereview.chromium.org/1302293002

Cr-Commit-Position: refs/heads/master@{#30291}

port 0492bb32 (r30203).

original commit message:

BUG=

Review URL: https://codereview.chromium.org/1306833002

Cr-Commit-Position: refs/heads/master@{#30290}

port 00df60d1 (r30219).

original commit message:

    Makes the following modifications to the interpreter builtins and
    InterpreterAssembler:
     - Adds an accumulator register and initializes it to undefined()
     - Adds a register file pointer register and use it instead of FramePointer to
       access registers
     - Modifies builtin to support functions with 0 regiters in the register file
     - Modifies builtin to Call rather than TailCall to first bytecode handler.

BUG=

Review URL: https://codereview.chromium.org/1304593002

Cr-Commit-Position: refs/heads/master@{#30289}

port f4c079d4 (r30107).

This is the appendix of 458dfe3b943edb3238917edfe9e2dde326cd1adb which misses
one modified file.

original commit message:

    There's no need to have one InstanceType per SIMD primitive type (this
    will not scale long-term).  Also reduce the amount of code duplication
    and make it more robust wrt adding new SIMD types.

BUG=

Review URL: https://codereview.chromium.org/1304963003

Cr-Commit-Position: refs/heads/master@{#30288}

BUG=chromium:520607
LOG=N

Review URL: https://codereview.chromium.org/1302273002

Cr-Commit-Position: refs/heads/master@{#30287}

Not all parenthesized AssignmentExpressions whose components are valid
binding patterns are valid arrow function formal parameters.  In
particular (a,b,c)() is not valid, and in general the existing code
wasn't catching the tail productions of ConditionalExpression,
BinaryExpression, PostfixExpression, LeftHandSideExpression,
and MemberExpression.

Thanks to Adrian Perez for the test case.

BUG=v8:4211
LOG=Y
R=rossberg@chromium.org

Review URL: https://codereview.chromium.org/1306583002

Cr-Commit-Position: refs/heads/master@{#30286}

We can use the script type to determine that instead. Script of type
TYPE_NATIVE are considered builtins, TYPE_NORMAL are not. The only exception
to this rule is the empty function, for which the script is TYPE_NATIVE
(observable by the debugger), but should be stringified to "function () {}"
instead of "function () { [native code] }". For this, I introduce a
hide_source flag on the script object.

We also use IsBuiltin and IsSubjectToDebugging interchangeably. For debugger,
we now use the latter, hiding the detail that only non-builtins are debuggable.

R=mstarzinger@chromium.org

Review URL: https://codereview.chromium.org/1292283004

Cr-Commit-Position: refs/heads/master@{#30285}

BUG=

Review URL: https://codereview.chromium.org/1292173003

Cr-Commit-Position: refs/heads/master@{#30284}