Code common with ObjectHasOwnProperty builtin was moved to CodeStubAssembler.

BUG=v8:2743
LOG=Y

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

R=jarin@chromium.org

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

BUG=chromium:598319
LOG=N

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

Restore the basic write barrier elimination that we used to run as part
of the simplified lowering phase (in ChangeLowering actually) before, by
moving the write barrier computation to SimplifiedLowering where we can
still look at types and consider the heap/isolate, and just update the
WriteBarrierKind in the FieldAccess/ElementAccess that we later use when
lowering to a machine Load/Store.

CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux64_tsan_rel
R=mstarzinger@chromium.org
BUG=v8:4969,chromium:608636
LOG=n

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

PushBack(end-of-input) is a little weird, but since
Utf16CharacterStream::Advance will advance pos_m, but not buffer_cursor_
when at the end of the stream, pushing back the end-of-input token needs
to do the exact inverse.

(The reason Advance does not advance buffer_cursor_ is that buffer_cursor_ is often dereferenced
 directly to access memory and so always needs to point to, well, memory.)
(The PushBack implementation for all other streams looks correct.)

R=rossberg@chromium.org
BUG=chromium:607903
LOG=Y

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

A wise man once said: If you want right result, compare right value.

R=rossberg@chromium.org
BUG=

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

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

The string operators not only read memory, but also write memory in case
of cons string flattening, so we better make sure to have the stub calls
in the effect chain.

R=jarin@chromium.org

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

R=ahaas@chromium.org,binji@chromium.org
BUG=

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

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

The Promise code previously used many names which were gratuitiously
different from the specification. This patch swaps in names from the
ES2015 spec, and inserts crossreferences to the spec. The patch
leaves mirrors over Promises unchanged for now, as these changes
could have compatibility risk.

R=cbruni@chromium.org

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

  port d1b3d426 (r35918)

  original commit message:
  Further refactor the pipeline to even run the first scheduler (part of
  the effect control linearization) concurrently. This temporarily
  disables most of the write barrier elimination, but we will get back to
  that later.

  Drive-by-fix: Remove the dead code from ChangeLowering, and stack
  allocate the Typer in the pipeline. Also migrate the AllocateStub to a
  native code builtin, so that we have the code object + a handle to it
  available all the time.

BUG=

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

R=bmeurer@chromium.org

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

Use the ShiftLeftStub, ShiftRightStub and ShiftRightLogicalStub in
JSGenericLowering instead of the old-style patching BinaryOpIC.

Also remove the machinery to support patching ICs in TurboFan
completely, as this was the last user of code patching in TurboFan!

R=yangguo@chromium.org

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

Rolling v8/build to 41661dd32f84419c998ffcb52bd5baff0fe94bc9

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

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

Yield expressions are not allowed in formal parameter initializers of
generators, but we weren't properly catching the case where the yield
expression appeared in the 'extends' clause of a class expression.

They also aren't allowed in arrow functions, which we were failing to
catch due to not looking at the obscurely-named "FormalParameterInitializerError"
bit of ExpressionClassifier.

This patch passes along an ExpressionClassifier when parsing class
expressions and accumulates the proper error for that case.

For the arrow function case, the fix is simply to check for the
"formal parameter initializer" error once we know we've parsed
an arrow function. The error message used for this has also
been made specific to yield expressions.

Tests are added both for the error case and the non-error cases (where
yield is used in such a position inside the class body).

BUG=v8:4966, v8:4968, v8:4974
LOG=n

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

BUG=v8:4985
LOG=n
TBR=littledan@chromium.org

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

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

R=adamk

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

changed the if/else block to fix the debug build
failure on PPC/s390.

R=adamk@chromium.org, mbrandy@us.ibm.com

BUG=
LOG=N

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

R=joransiu@ca.ibm.com, mbrandy@us.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

Fix A couple places which could cause upper 32bit corruption

R=joransiu@ca.ibm.com, mbrandy@us.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

Takes the SIMD runtime intrinsics as a starting point for defining TF machine operators. The rationale for omitting functions is:

 - Check functions.
 - 'FromXxxBits' functions. These are essentially casts.
 - UInt constructors. int and uint aren't distinguished in wasm.
 - Uint functions, except where their behavior is bitwise different from the Int function.

Some operators are typeless, i.e. they are the same for multiple related types, e.g. logical ops for int types, load/store for float and int types. Use a 'Simd128' prefix for these operators.

Skipped fns:

Float32x4Check
Float32x4FromInt32x4Bits
Float32x4FromUint32x4Bits
Float32x4FromInt16x8Bits
Float32x4FromUint16x8Bits
Float32x4FromInt8x16Bits
Float32x4FromUint8x16Bits

Int32x4Check
Int32x4FromUint32x4
Int32x4FromFloat32x4Bits
Int32x4FromUint32x4Bits
Int32x4FromInt16x8Bits
Int32x4FromUint16x8Bits
Int32x4FromInt8x16Bits
Int32x4FromUint8x16Bits

CreateUint32x4
Uint32x4Check
Uint32x4ExtractLane
Uint32x4ReplaceLane
Uint32x4Add
Uint32x4Sub
Uint32x4Mul
Uint32x4And
Uint32x4Or
Uint32x4Xor
Uint32x4Not
Uint32x4Equal
Uint32x4NotEqual
Uint32x4Select
Uint32x4Swizzle
Uint32x4Shuffle
Uint32x4FromInt32x4
Uint32x4FromFloat32x4Bits
Uint32x4FromInt32x4Bits
Uint32x4FromInt16x8Bits
Uint32x4FromUint16x8Bits
Uint32x4FromInt8x16Bits
Uint32x4FromUint8x16Bits

Bool32x4Check

Int16x8Check
Int16x8FromUint16x8
Int16x8FromFloat32x4Bits
Int16x8FromInt32x4Bits
Int16x8FromUint32x4Bits
Int16x8FromUint16x8Bits
Int16x8FromInt8x16Bits
Int16x8FromUint8x16Bits

CreateUint16x8
Uint16x8Check
Uint16x8ExtractLane
Uint16x8ReplaceLane
Uint16x8Add
Uint16x8Sub
Uint16x8Mul
Uint16x8And
Uint16x8Or
Uint16x8Xor
Uint16x8Not
Uint16x8Equal
Uint16x8NotEqual
Uint16x8Select
Uint16x8Swizzle
Uint16x8Shuffle
Uint16x8FromInt16x8
Uint16x8FromFloat32x4Bits
Uint16x8FromInt32x4Bits
Uint16x8FromUint32x4Bits
Uint16x8FromInt16x8Bits
Uint16x8FromInt8x16Bits
Uint16x8FromUint8x16Bits

Bool16x8Check

Int8x16Check
Int8x16FromUint8x16
Int8x16FromFloat32x4Bits
Int8x16FromInt32x4Bits
Int8x16FromUint32x4Bits
Int8x16FromInt16x8Bits
Int8x16FromUint16x8Bits
Int8x16FromUint8x16Bits

CreateUint8x16
Uint8x16Check
Uint8x16ExtractLane
Uint8x16ReplaceLane
Uint8x16Add
Uint8x16Sub
Uint8x16Mul
Uint8x16And
Uint8x16Or
Uint8x16Xor
Uint8x16Not
Uint8x16Equal
Uint8x16NotEqual
Uint8x16Select
Uint8x16Swizzle
Uint8x16Shuffle
Uint8x16FromInt8x16
Uint8x16FromFloat32x4Bits
Uint8x16FromInt32x4Bits
Uint8x16FromUint32x4Bits
Uint8x16FromInt16x8Bits
Uint8x16FromUint16x8Bits
Uint8x16FromInt8x16Bits

Bool8x16Check

Generic operators for Float, Int types:

Simd128Load
Simd128Load1
Simd128Load2
Simd128Load3
Simd128Store
Simd128Store1
Simd128Store2
Simd128Store3

Generic operators for Int types:

Simd128And
Simd128Or
Simd128Xor
Simd128Not

LOG=N
BUG=v8:4124

Committed: https://crrev.com/3831d41e4ce7b162775732cb6ac1f8139e60aa30
Cr-Commit-Position: refs/heads/master@{#35213}

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

    Port d1b3d426

    Original commit message:

        Further refactor the pipeline to even run the first scheduler (part of
        the effect control linearization) concurrently. This temporarily
        disables most of the write barrier elimination, but we will get back to
        that later.

        Drive-by-fix: Remove the dead code from ChangeLowering, and stack
        allocate the Typer in the pipeline. Also migrate the AllocateStub to a
        native code builtin, so that we have the code object + a handle to it
        available all the time.

    R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com

BUG=

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

The ECMA 402 implementation previously pushed directly to real
Arrays, which risks having observably incorrect behavior in the
presence of monkey patching. This patch uses InternalArrays instead
to avoid that hazard.

R=jshin@chromium.org,yangguo@chromium.org
BUG=chromium:604299
LOG=N

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

For proxy object this methods returns target value, handler object and is revoked flag.

R=yangguo@chromium.org,cbruni@chromium.org
BUG=chromium:588705
LOG=Y

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

Our implementation of the spec got one comparison wrong, at
step 19.d.iii (we were comparing against 'q' instead of 'p').

R=littledan@chromium.org
BUG=chromium:607566
LOG=n

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

It truned out we can enter nested message loop and call
SetIdle from inside the compilation in some obscure
situations. To not whitelist all the possible StateTag values,
we'd better ignore this call when not profiling as it has
no effect anyway.

This patch also reverts DCHECK change from https://codereview.chromium.org/1922703005/.

BUG=none
LOG=N

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

Also mark VisitSuperCallReference as unreachable, as it's handled by VisitCall.

R=mstarzinger@chromium.org
BUG=v8:4967
LOG=n

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

Currently GetStackSample doesn't support simulator, thus sampler is aware of
simulator, but since we are moving it out, it shouldn't have knowledge of
simulator. This patch moves the logic using simulator accessible
to Isolate::GetStackSample, so that it supports simulator.

BUG=v8:4956
LOG=n

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

gn builds are missing Windows manifests for d8.exe and
mksnapshot.exe. These manifests are necessary in order to get
predictable behavior on Windows.

LOG=N
BUG=602505

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

Previous attempt: https://codereview.chromium.org/1924403002

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

R=rossberg@chromium.org,ahaas@chromium.org
BUG=

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

This avoids weird control flow when the bytecode generator skips dead code containing yields.

BUG=v8:4907
LOG=n

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

BUG=chromium:474921
LOG=n

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

Port d1b3d426

Original commit message:

    Further refactor the pipeline to even run the first scheduler (part of
    the effect control linearization) concurrently. This temporarily
    disables most of the write barrier elimination, but we will get back to
    that later.

    Drive-by-fix: Remove the dead code from ChangeLowering, and stack
    allocate the Typer in the pipeline. Also migrate the AllocateStub to a
    native code builtin, so that we have the code object + a handle to it
    available all the time.

R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com

BUG=v8:4969
LOG=N

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

BUG=v8:4866
LOG=n
NOTRY=true
TBR=yangguo@chromium.org

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

This removes the CompilationInfoWithZone class, which was used to
allocate a CompilationInfo on the C-heap. By now the CompilationJob is
the single object being allocated on the C-heap and passed between the
main thread and the compilation thread. Structs requiring destruction
can be embedded within that CompilationJob. This simplifies involved
lifetimes by coupling all lifetimes to one single object.

R=bmeurer@chromium.org

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

The Wasm suite reports both compile time and code size, however,
perf-to-html.py elides one of the results (compile time, in this case).

This affects the effectiveness of results reported by perf try bot runs.

This CL addresses that.

BUG=

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

The compilation pipeline is correctly guarding against accidental
tier-ups by now, the tests in question should no longer fail.

R=yangguo@chromium.org
BUG=v8:4961
LOG=n

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

BUG=chromium:608312
LOG=NO

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