R=jochen@chromium.org

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

This is requested for Node.js N-API. Tests to be added.

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

This fixes the validation of "|0" annotations of call sites that are
used to indicate a "signed" return type of functions. We use lookahead
during call validation and request deferred validation as part of the
actual OR-expression. Special care has to be taken to get precedence
levels of all involved operators right.

R=clemensh@chromium.org
TEST=mjsunit/asm/call-annotation
BUG=v8:6183

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

The condition only applies in unicode mode, where any lone surrogates
are desugared into a character class (and will not be considered in this
optimization). Non-unicode mode treats lone surrogates exactly like
any other codepoint.

BUG=chromium:711092

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

In eval scripts, the source code position can be 0 rather
than greater than 0.

Add regression test.

Drive-by fix: unrelated typo.

Bug: 707223
Change-Id: If52c0736daac3ad42ac6d324eb8ec5f1798f6f5a
Reviewed-on: https://chromium-review.googlesource.com/476630Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44637}

This issue was fixed in VisitWord64And in 2f8ad11f. Port the fix to
VisitWord32And.

BUG=

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

Bug: chromium:710428,v8:6248
Change-Id: I70430d5a200199563bf5468a6cc80614307f63e6
Reviewed-on: https://chromium-review.googlesource.com/474847Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44635}

This CL implements the proposed change to show information about
WebAssembly values and call frames via the inspector interface.
Each interpreted WebAssembly frame will have two scopes: A global scope
showing information about the memory (to be extended for globals), and
a local scope showing information about parameters, local variables, and
stack values.
Names of local variables will be added later.

R=ahaas@chromium.org, yangguo@chromium.org
BUG=v8:6245,v8:5822

Change-Id: I0a35fddd0a353933c86adf62083233b08098a2c7
Reviewed-on: https://chromium-review.googlesource.com/474865
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44633}

This fixes the existing lowering of {JSGetSuperConstructor} nodes to
unconditional throws. The above operator is marked as {kNoWrite} but
runtime calls are not marked as such. Any deoptimizing operation after
the throw would not be able to find a valid {Checkpoint}. We remove the
lowering case in question.

R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-6248
BUG=v8:6248

Change-Id: I22c922947336254502f698b02f944cf35dd8688a
Reviewed-on: https://chromium-review.googlesource.com/476570Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44632}

When the incoming value to ChangeFloat64ToTagged is in Smi range, we
represent it as Smi instead of a HeapNumber. This addresses a range of
problems where TurboFan unnecessarily deoptimizes because an operation
learned Smi feedback in Ignition, but was then confronted with a tagged
HeapNumber in TurboFan, just because the value was also represented as
unboxed double somewhere in the meantime.

BUG=v8:6256
R=yangguo@chromium.org

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

Adds some benchmarks copied from v8:4762.

BUG=v8:4762, v8:5460
R=adamk@chromium.org

Change-Id: I0b96080042781c2c46c0c8a3896a921bde97c1e5
Reviewed-on: https://chromium-review.googlesource.com/475934Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#44629}

It's required by the spec -- and observable -- that the index be validated
before the conversion of the value(s) via ToInteger.

The previous implementation also had an old test for validating the atomic
index, which has now been switched to ToIndex.

This also exposed an issue in the ia32 code generator: cmpxchg_b requires a
byte register, but the ia32 instruction selector was ensuring that the
new_value was a byte register, not the TempRegister. This change forces the
temp register to use edx, which always can be used as a byte register (dl).
This is the same behavior as currently used in UseByteRegister.

BUG=v8:4614
R=jarin@chromium.org,jkummerow@chromium.org

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

We currently store it in parent stack trace but stacks with the same parent can have different creations stacks.

BUG=v8:6189
R=dgozman@chromium.org

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

The arm64 MacroAssembler expects buffer_size to be an unsigned, not a
size_t.

BUG=chromium:710913

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

Usually program doesn't contain a lot of different stack frames in collected stack trace.

BUG=v8:6189
R=yangguo@chromium.orr
TBR=bmeurer@chromium.org

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

The BytecodePipeline is no longer used by any optimizers, so remove it and
connect the BytecodeArrayBuilder directly to the BytecodeWriter.

Also remove some functions from BytecodeNode which are no longer used.

BUG=v8:6194

Change-Id: Id2ec94ff1d4db41b108a778100459283fbb2256c
Reviewed-on: https://chromium-review.googlesource.com/471528Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44619}

This reverts commit b9194e93.

Reason for revert: Makes old pipeline flaky with custom snapshot:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20custom%20snapshot%20-%20debug/builds/14049

Original change's description:
> [heap-verification] Increase verification for arguments objects
> 
> BUG: v8:6251
> Change-Id: I8a6dd528656a69c7910770acaf2133830b60c291
> Reviewed-on: https://chromium-review.googlesource.com/475651
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#44609}

TBR=jkummerow@chromium.org,cbruni@chromium.org,v8-reviews@googlegroups.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

Change-Id: Iedfdad290bf4f5f6ec2534e8c5378a7cc195db82
Reviewed-on: https://chromium-review.googlesource.com/475719Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44616}

Unfortunately, this test cannot test that a function was really skipped (i.e.,
not parsed).

BUG=v8:5516

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

Revert of [wasm] instantiate expressed in terms of compile (patchset #6 id:140001 of https://codereview.chromium.org/2806073002/ )

Reason for revert:
Roll blocker: https://bugs.chromium.org/p/chromium/issues/detail?id=710824

Original issue's description:
> [wasm] instantiate expressed in terms of compile
>
> Today, the semantics of:
>
> WebAssembly.instantiate
>
> and
>
> WebAssembly.compile().then(new WebAssemblyInstance)
>
> are subtly different, to the point where attempting the proposed
> change uncovered bugs.
>
> In the future, it's possible that .instantiate actually have different
> semantics - if we pre-specialized to the provided ffi, for example.
> Right now that's not the case.
>
> This CL:
> - gets our implementation closer to what developers may write using
> the compile -> new Instance alternative, in particular wrt promise
> creation. By reusing code paths, we uncover more bugs, and keep
> maintenance cost lower.
>
> - it gives us the response-based WebAssembly.instantiate implicitly.
> Otherwise, we'd need that same implementation on the blink side. The
> negative is maintenance: imagine if the bugs I mentioned could only be
> found when running in Blink.
>
> BUG=chromium:697028
>
> Review-Url: https://codereview.chromium.org/2806073002
> Cr-Commit-Position: refs/heads/master@{#44592}
> Committed: https://chromium.googlesource.com/v8/v8/+/7829af3275ff4644a2d0a1270abe1a1e4415e9fb

TBR=bradnelson@chromium.org,ahaas@chromium.org,adamk@chromium.org,mtrofin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:697028

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

BUG: v8:6251
Change-Id: I8a6dd528656a69c7910770acaf2133830b60c291
Reviewed-on: https://chromium-review.googlesource.com/475651
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44609}

We used to reserve the 0-th embedder data field for the debug
context id. This is no longer necessary since the inspector
has migrated to be part of V8. This makes the API a bit simpler.

R=clemensh@chromium.org, jochen@chromium.org, kozyatinskiy@chromium.org
BUG=v8:5530

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

The hole NaN should also have proper Type::Hole, and not silently hide
in the Type::Number. This way we can remove all the special casing for
the hole NaN, and we also finally get the CheckNumber right.

This also allows us to remove some ducktape from the Deoptimizer, as for
escape analyzed FixedDoubleArrays we always pass the hole value now to
represent the actual holes.

Also-By: jarin@chromium.org
BUG=chromium:684208,chromium:709753,v8:5267
R=jarin@chromium.org

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

The local variables were parsed two times, which in fact doubled the
amount of local variables allocated for each called function.
This was costing memory and performance. As the additional local
variables were never used, we did not recognize this before.

Add a test case for locals and stack values of interpreted frames.

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

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

RationalizeConsecutiveAtoms optimizes ab|ac|az to a(?:b|c|d).
Ensure that this optimization does not split surrogate pairs in unicode
mode.

BUG=chromium:641091

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

As of crrev.com/2760213003, the CheckBounds operator passes a truncation
that identfies zero and minus zero. However that was not reflected in
the typing rule, and as such the type of CheckBounds(-0,length) was
always Type::None. That confused the typed alias analysis in the
LoadElimination and led to ignoring StoreElement nodes.

BUG=chromium:708050
R=jarin@chromium.org

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

Add support for F32x4Abs, F32x4Neg, F32x4RecipApprox,
F32x4RecipRefine, F32x4RecipSqrtApprox, F32x4RecipSqrtRefine,
F32x4Add, F32x4Sub, F32x4Mul, F32x4Max, F32x4Min,
F32x4Eq, F32x4Ne, F32x4Lt, F32x4Le, I32x4SConvertF32x4,
I32x4UConvertF32x4 operations for mips32 and mips64
architectures.

BUG=

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

This change mirrors the semantics for derived class constructors. This
change doesn't affect non class constructors.

This change could potentially break web compat. More details:
https://github.com/tc39/ecma262/pull/469

Bug=v8:5536

Change-Id: I519599949523733332d0b35e4f8d9ecb01cac495
Reviewed-on: https://chromium-review.googlesource.com/461225Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44594}

Today, the semantics of:

WebAssembly.instantiate

and

WebAssembly.compile().then(new WebAssemblyInstance)

are subtly different, to the point where attempting the proposed
change uncovered bugs.

In the future, it's possible that .instantiate actually have different
semantics - if we pre-specialized to the provided ffi, for example.
Right now that's not the case.

This CL:
- gets our implementation closer to what developers may write using
the compile -> new Instance alternative, in particular wrt promise
creation. By reusing code paths, we uncover more bugs, and keep
maintenance cost lower.

- it gives us the response-based WebAssembly.instantiate implicitly.
Otherwise, we'd need that same implementation on the blink side. The
negative is maintenance: imagine if the bugs I mentioned could only be
found when running in Blink.

BUG=chromium:697028

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

This also fixes an existing discrepancy.

BUG=v8:6017

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

R=clemensh@chromium.org
BUG=v8:6127

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

Per https://github.com/tc39/test262/pull/956, André believes that ASI
should be permitted in these situations.

BUG=
R=marja@chromium.org, adamk@chromium.org, littledan@chromium.org

Change-Id: I5602d8a507576607750ffa9e873e1bfa53dd3523
Reviewed-on: https://chromium-review.googlesource.com/472568Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#44585}

The test "assertThrows(builder.instantiate)" threw a TypeError before,
which made the test pass, but not because of the feature we wanted to
test.
This CL fixes the test to call builder.instantiate correctly, and also
tests for the correct error message.

Drive-by fix: Fix {expected} and {found} parameters in assertThrows.

R=ahaas@chromium.org

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

Adds a collection of call bytecodes which have an implicit undefined
receiver argument, for cases such as global calls where we know that the
receiver has to be undefined. This way we can skip an LdaUndefined,
decrease bytecode register pressure, and set a more accurate
ConvertReceiverMode on the interpreter and TurboFan call.

As a side effect, the "normal" Call bytecode now becomes a rare case
(only with calls and super property calls), so we get rid of its 0-2
argument special cases and modify CallProperty[N] to use the
NotNullOrUndefined ConvertReceiverMode.

Reland of https://chromium-review.googlesource.com/c/463287 after fixing
tests in https://codereview.chromium.org/2813873002.

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

After [1] we return JSArray with internal structs, we should return JSObjects instead.

[1] https://codereview.chromium.org/2789073002

BUG=v8:6189
R=yangguo@chromium.org

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

See https://tc39.github.io/proposal-regexp-unicode-property-escapes

R=jgruber@chromium.org
BUG=v8:4743

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

This constructs different typed arrays from different types of other
typed arrays, hopefully countering microbenchmarks which are able to
optimize for exactly one pair of types.

Bug: v8:5977
Change-Id: Ie3b07d6ecaaca6db0be410e902e437a2a643d71c
Reviewed-on: https://chromium-review.googlesource.com/474748Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44576}

Reland of [date] Add ICU backend for timezone info behind a flag (patchset #1 id:1 of https://codereview.chromium.org/2811103002/ )

Reason for revert:
Reland with tests marked as off in no-i18n mode

Original issue's description:
> Revert of [date] Add ICU backend for timezone info behind a flag (patchset #17 id:320001 of https://codereview.chromium.org/2724373002/ )
>
> Reason for revert:
> Breaks noi18n:
> https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20noi18n%20-%20debug/builds/13314
>
> Original issue's description:
> > [date] Add ICU backend for timezone info behind a flag
> >
> > This patch implements a timezone backend which is based on ICU, rather
> > than operating system calls. It can be turned on by passing the
> > --icu-timezone-data flag. The goal here is to take advantage of ICU's
> > data, which is more complete than the data that some system calls expose.
> > For example, without any special code, this patch fixes the time zone
> > of Lord Howe Island to have a correct 30 minute DST offset, rather than
> > 60 minutes as the OS backends assume it to have.
> >
> > Unfortunately, the parenthized timezone name in Date.prototype.toString()
> > differs across platforms. This patch chooses the long timezone name,
> > which matches Windows behavior and might be the most intelligible, but
> > the web compatibility impact is unclear.
> >
> > BUG=v8:6031,v8:2137,v8:6076
> >
> > Review-Url: https://codereview.chromium.org/2724373002
> > Cr-Commit-Position: refs/heads/master@{#44562}
> > Committed: https://chromium.googlesource.com/v8/v8/+/b213f2399038a615cdfbfa0201cddc113d304018
>
> TBR=ulan@chromium.org,jshin@chromium.org,jgruber@chromium.org,littledan@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:6031,v8:2137,v8:6076
>
> Review-Url: https://codereview.chromium.org/2811103002
> Cr-Commit-Position: refs/heads/master@{#44565}
> Committed: https://chromium.googlesource.com/v8/v8/+/13ad50811024ace5623d5d4d13cea4ef21f4affd

TBR=ulan@chromium.org,jshin@chromium.org,jgruber@chromium.org,machenbach@chromium.org
BUG=v8:6031,v8:2137,v8:6076

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

This is a noop right now as we run test262 without variants on asan.

We'll use the status file to whitelist the variants in a synchronous way in v8 after the infra change lands to activate them.

Bug: chromium:710428
NOTRY=true

Change-Id: I146bbc648775ef0e250c16695b956ecd1d6e105e
Reviewed-on: https://chromium-review.googlesource.com/474845
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44574}

This a step towards using CompilerDispatcher in parallel
parsing.

BUG=v8:6093

Change-Id: Idee84105e342950badb5694fa2a850e05430abaa
Reviewed-on: https://chromium-review.googlesource.com/473246
Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44573}

A really slight change in behaviour introduced by
https://github.com/tc39/proposal-async-iteration/commit/395b2e3b2f5acb62f9fae11c5e189423d4af50e6

Just swaps the order that properties are loaded from an iterator result
object in the various Async-from-Sync Iterator methods.

Fixes for the test262 tests have been submitted already (https://github.com/tc39/test262/pull/961).

BUG=v8:5855, v8:6242
R=littledan@chromium.org, jwolfe@igalia.com,

Change-Id: I1ff0e1b7758c126d02aec27d67ceeb15b91c06cf
Reviewed-on: https://chromium-review.googlesource.com/474087Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#44572}