1. use ltr/ltgr when possible
2. combine compares with possible load

R=joransiu@ca.ibm.com, bjaideep@ca.ibm.com

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

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/c8fd116..1ecc6e7

Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/574285d..36a5082

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/7764539..799a6a3

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

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

https://crrev.com/2500363002 updated FunctionTemplate::HasInstance to
follow the hidden prototype chain of a global proxy to the global
object. However, remote contexts don't have a global object to check;
instead, teach the instance check knows about the conventions of
global proxy setup and have it also check the constructor's prototype.

Similarly, also teach Object::FindInstanceInPrototypeChain about the
unusual conventions for remote contexts.

BUG=527190

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

For functions declared in source code, the .toString() representation
will be an excerpt of the source code.
* For functions declared with the "function" keyword, the excerpt
  starts at the "function" or "async" keyword and ends at the final "}".
  The previous behavior would start the excerpt at the "(" of the
  parameter list, and prepend a canonical `"function " + name` or
  similar, which would discard comments and formatting surrounding the
  function's name. Anonymous functions declared as function expressions
  no longer get the name "anonymous" in their toString representation.
* For methods, the excerpt starts at the "get", "set", "*" (for
  generator methods), or property name, whichever comes first.
  Previously, the toString representation for methods would use a
  canonical prefix before the "(" of the parameter list. Note that any
  "static" keyword is omitted.
* For arrow functions and class declarations, the excerpt is unchanged.

For functions created with the Function, GeneratorFunction, or
AsyncFunction constructors:
* The string separating the parameter text and body text is now
  "\n) {\n", where previously it was "\n/*``*/) {\n" or ") {\n".
* At one point, newline normalization was required by the spec here,
  but that was removed from the spec, and so this CL does not do it.

Included in this CL is a fix for CreateDynamicFunction parsing. ')'
and '`' characters in the parameter string are no longer disallowed,
and Function("a=function(", "}){") is no longer allowed.

BUG=v8:4958, v8:4230

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

Without relying on the stub cache.

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

Before this patch, the registers needed for bytecode dispatch in interpreter
handlers were inconsistently stored in the interpreter frame and/or kept in
values that remained live across calls.

After this patch, these registers are explicitly reloaded after calls, making it
possible to elide the spills of those registers before the call in many cases.

Some highlights from the CL:

* Added methods to the CSA and InterpreterAssembler to efficiently store and
  load Smis values and Smi interpreter registers on x64 without explicit
  tagging/untagging.

* Created Variables for all of the interpreter-internal values that need to be
  reloaded before bytecode dispatch at the end of an interpreter handler.

* The bytecode offset can be written out early in a handler by marking it
  has having a call along it's critical path. By moving this early in a
  handler, it becomes possible to use memory operands for pushes used to
  marshall parameters when making calls.

Change-Id: Icf8d7798789f88a4489e06a7092616bbbb881577
Reviewed-on: https://chromium-review.googlesource.com/442566
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43260}

This changes most callers of ParseScopedStatement to call a new, simpler form
of ParseStatement, which takes only |labels| and |ok|. This allows us to remove
the |legacy| attribute from ParseScopedStatement.

The only remaining caller of ParseScopedStatement is ParseIfStatement.

This patch is a strict refactoring, and should change no behavior.

R=littledan@chromium.org

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

ES2017 forbids the sequence of tokens "let [" in in expression statements [1].

This CL makes ParserBase report those instances as SyntaxError. It also adds a
customised error message for that, because the standard "Unexpected token" is
not applicable: "let" itself is not forbidden in those context, only the
sequence of "let [".

[1] https://tc39.github.io/ecma262/#sec-expression-statement

BUG=v8:5686

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

This adds the possibility to specify a python script for post-processing stdout.

This also adds some system tests for testing the new feature.

NOTRY=true

Change-Id: I0383afb3e23513629508feeb639ed2dfce56b54a
Reviewed-on: https://chromium-review.googlesource.com/443449Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43257}

This improves the filter deciding whether a checkpoint needs to be
created. We now keep track of whether a node having an observable
side-effect has been created, allowing to elide checkpoint that are
provably effect-dominated by another checkpoint already.

By now the initial graphs contain an increasing amount of nodes marked
with {Operator::kNoWrite}, making this optimization worthwhile.

R=jarin@chromium.org

Change-Id: Ie7ffb67e1ab081ef7aa3017675afbe5f9e7601ab
Reviewed-on: https://chromium-review.googlesource.com/443466Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43256}

This upgrades to a precompiled plugin version including:
https://chromium.googlesource.com/v8/v8/+/4b0edcf7

BUG=v8:5970
TBR=clemensh@chromium.org,mstarzinger@chromium.org

Change-Id: I28ecdd568e4bc075533b3d14b7946a4a7ce5f9e0
Reviewed-on: https://chromium-review.googlesource.com/443648
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43255}

Errors are swallowed by promises, so just exit with stack trace.

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

The default locale can be changed in some environments with environment
variables. These environment variables used to allow the system to get
into an invalid state, where the default locale was unsupported. This
patch detects that case and falls back to "und" as the default locale
if there is an Intl service which does not support the locale that ICU
reports as the default. It also has a slight cleanup of surrounding code.

I haven't gone through the work to set up an automated test, as triggering
the case requires setting environment variables, which our tests don't tend
to do, but I tested interactively as follows:

dehrenberg@dehrenberg:~/v8/v8$ LC_ALL="tlh-FR" rlwrap out/Release/d8
V8 version 5.7.0 (candidate)
d8> new Intl.NumberFormat("foo").resolvedOptions().locale
"und"
d8> new Intl.NumberFormat().resolvedOptions().locale
"und"
d8>

dehrenberg@dehrenberg:~/v8/v8$ LC_ALL="de" rlwrap out/Release/d8
V8 version 5.7.0 (candidate)
d8> new Intl.NumberFormat().resolvedOptions().locale
"de"
d8> new Intl.NumberFormat("foo").resolvedOptions().locale
"de"
d8>

BUG=v8:4216

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

This is a workaround for the fact that %SetCode can "lose" the script for a js native. If the js native is re-initialized (for a Realm or something), then the source SharedFunctionInfo won't have a script anymore. Nonetheless, we may want to optimize the function. If we've compiled bytecode, then we can compile optimized code without a script.

Here, we carve out a special exception for this case, so that we can turn on the --mark-shared-functions-for-tier-up.

BUG=v8:5946
R=leszeks@chromium.org

Review-Url: https://codereview.chromium.org/2684033007
Cr-Original-Commit-Position: refs/heads/master@{#43240}
Committed: https://chromium.googlesource.com/v8/v8/+/4123a3dd790495c40cf839990318a85c146e057d
Review-Url: https://codereview.chromium.org/2684033007
Cr-Commit-Position: refs/heads/master@{#43252}

Enforce the invariant that unreachable implicates an empty live set and
fix the implementation of |= and &= operator.
This is a fix-up for http://crrev.com/2694103005.

R=vegorov@chromium.org
CC=mstarzinger@chromium.org, machenbach@chromium.org
BUG=v8:5970

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

We were looking at the unreachable flag or stack_depth of the target frame
instead of the current one in a couple of places (most notably BreakTo).
This change fixes these bugs and makes us pass the latest spec tests for
br_table validation. Also need to ensure that br_table targets have consistent
types, which is not implied if the stack is polymorphic.

R=titzer@chromium.org
BUG=

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

The serializer won't ever write a more complex object. Not validating this
allows other things to be used as keys, and converted to string when the
property set actually occurs. It turns out this gives an opportunity to trigger
OOM by giving an object a key which is a very large sparse array (whose string
representation is very large).

This case is now rejected by the deserializer.

BUG=chromium:686511

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

The SpeculativeNumberOp helper lives now in js-type-hint-lowering.cc and
is no longer needed in js-typed-lowering.cc.

R=mstarzinger@chromium.org
BUG=

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

BUG=v8:5974

Change-Id: If79ff5c29bea79ebf8019c4a8e72d2bd7c6b9029
Reviewed-on: https://chromium-review.googlesource.com/443448
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43247}

BUG=v8:5880
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_noi18n_rel_ng

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

One optimization in the machine-operator-reducer did not consider that
that word32 shift left instructions only consider the last 5 bits of
the shift input.

The issue only occurs for WebAssembly because in JavaScript we always
add a "& 0xf" on the shift value to the TurboFan graph.

For additional background: The JavaScript and WebAssembly spec both
say that only the last 5 bits of the shift value are used in the
word32-shift-left operation. This means that an "x << 0x29", in the
code is actually executed as "x << 0x09". Therefore the changes in
this CL are okay because they mask the last 5 bit of the shift value.

BUG=chromium:689450

Change-Id: Id92f298ed6d7f1714b109b3f4fbcecd5ac6d30f7
Reviewed-on: https://chromium-review.googlesource.com/439312Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43245}

Map OOM breaks generated by inspector to DebugEvent.OOM.
This avoids generating unintentional DebugEvent.Break events.

Also be more future-proof in event categorization.

On a related note, this CL also fixes a DCHECK in
Runtime::GetFrameDetails.

The receiver needs to be grabbed from the inlined frame, not
the outer optimized frame. Optimized frames only provide the
receiver on a best-effort basis.

BUG=v8:5950

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

R=eholk@chromium.org

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

Revert of Allow a ParseInfo without a script for %SetCode users (patchset #5 id:220001 of https://codereview.chromium.org/2684033007/ )

Reason for revert:
Please remove the file in status file too. Breaks presubmit:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20presubmit/builds/14754

Or lets call it post-submit :(

Original issue's description:
> This is a workaround for the fact that %SetCode can "lose" the script for a js native. If the js native is re-initialized (for a Realm or something), then the source SharedFunctionInfo won't have a script anymore. Nonetheless, we may want to optimize the function. If we've compiled bytecode, then we can compile optimized code without a script.
>
> Here, we carve out a special exception for this case, so that we can turn on the --mark-shared-functions-for-tier-up.
>
> BUG=v8:5946
> R=leszeks@chromium.org
>
> Review-Url: https://codereview.chromium.org/2684033007
> Cr-Commit-Position: refs/heads/master@{#43240}
> Committed: https://chromium.googlesource.com/v8/v8/+/4123a3dd790495c40cf839990318a85c146e057d

TBR=leszeks@chromium.org,mstarzinger@chromium.org,marja@chromium.org,mvstanton@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5946

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

Produce the same scopes / variables for parameters (part 3).

This CL fixes the ordering + variable types in PreParser when there are
simple parameters + a rest parameter. In that case, Parser declares
unnamed temporaries for the non-rest params, then the rest param, then
the named variables (which are not parameters) for the non-rest params.

BUG=v8:5516
R=vogelheim@chromium.org

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

This is a workaround for the fact that %SetCode can "lose" the script for a js native. If the js native is re-initialized (for a Realm or something), then the source SharedFunctionInfo won't have a script anymore. Nonetheless, we may want to optimize the function. If we've compiled bytecode, then we can compile optimized code without a script.

Here, we carve out a special exception for this case, so that we can turn on the --mark-shared-functions-for-tier-up.

BUG=v8:5946
R=leszeks@chromium.org

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

ES2016 changed the default timezone of dates to be conditional on
whether a time is included. The semantics were a compromise approach
based on web compatibility feedback from V8, but until now, we have been
shipping ES5.1 default timezone semantics. This patch implements the
new semantics, following ChakraCore and SpiderMonkey (though JSC
implements V8's previous semantics).

BUG=chromium:589858

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

Patch adopted from mvstanton@ ( https://codereview.chromium.org/2657413002/ )

BUG=

Change-Id: I4296b3d5694116e250a6bb88296fbed0f0c444e6
Reviewed-on: https://chromium-review.googlesource.com/443246Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43238}

This is in order to prevent accidental bugs in desugarings.

R=adamk@chromium.org
BUG=v8:5636

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

BUG=chromium:690003

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

This handles arithmetic addition operations during the early type-hint
lowering (i.e. during graph construction). The string addition case is
still handled by {JSTypedLowering} as it needs static type information.

R=bmeurer@chromium.org

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

@@replace has a pretty complex implementation, taking different paths
for various situations (e.g.: global/nonglobal regexp, functional/string
replace argument, etc.). Each of these paths must implement similar
logic for calling into the RegExpBuiltinExec spec operation, and many
paths get this subtly wrong.

This CL fixes a couple of issues related to the way @@replace handles lastIndex:
* All paths now respect lastIndex when calling into exec (some used to assume 0).
* lastIndex is now advanced after a successful match for sticky regexps.
* lastIndex is now only reset to 0 on failure for sticky regexps.

BUG=v8:5361

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

The parser was finalizing the inner block scope, but not clearing the
inner block's scope pointer. This doesn't (yet) have any behavioral
difference, but makes it easier to make assumptions about the structure
of the AST vs the scope chain.

R=neis@chromium.org

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

This was omitted in:
https://codereview.chromium.org/2615623003

TBR=clemensh@chromium.org,mtrofin@chromium.org
NOTRY=true

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

The inspector uses V8's API handles and should not access
V8 internals. This change makes sure it can use the coverage
data in an encapsulated way.

R=jgruber@chromium.org, kozyatinskiy@chromium.org
BUG=v8:5808

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

- Clear flags to avoid the quite expensive query for whether this page
  is to be swept.
- Use a vector instead of a list as we always expect a small number of
  pages to go through the pool and we want to avoid memory management on
  this path.

BUG=

Change-Id: If3c0ad480b8e4f3ccf5a0ef43200c5269822245d
Reviewed-on: https://chromium-review.googlesource.com/443248
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43230}

This wraps float arrays with a proxy to make raw buffer use slow paths avoiding different NAN patterns.

This also mocks out large typed arrays when passing the lenth as third constructor parameter.

BUG=chromium:691287,chromium:690898
NOTRY=true

Change-Id: Ic4295b0d8690e5209aceeda9ed93efdd580194c0
Reviewed-on: https://chromium-review.googlesource.com/441624
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43229}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/5af1827..c8fd116

Rolling v8/test/wasm-js: https://chromium.googlesource.com/external/github.com/WebAssembly/spec/+log/680fa9a..b96d096

Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/7336c94..574285d

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

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

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

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

R=gsathya@chromium.org

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