For denominators that are powers of two, replace Float64 division with
multiplication by the reciprocal.

Additionally, replace division by -1 with negation, and multiplication by two
with addition.

BUG=

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

Rename JSModule to Module and make it a Struct rather than a JSObject.  We will
later add a separate JSModuleNamespace object to implement the 'import * as foo'
syntax.

BUG=v8:1569

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

This CL also cleans up related interface descriptors:
1) unused StoreTransitionDescriptor is removed and VectorStoreTransitionDescriptor is
renamed to StoreTransitionDescriptor.
2) on ia32/x87 architectures slot and vector are passed on the stack (dispatcher/handlers
cleanup will be addressed in a separate CL).

These two stub ports have to be combined in one CL because:
1) without changing the StoreTransitionDescriptor TF was not able to compile them
on ia32/x87 (because of lack of registers),
2) it was not possible to change the descriptor first because Crankshaft was not able
to deal with the stack allocated parameters in case of a stub failure.

TBR=jkummerow@chromium.org
BUG=v8:5269

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

Revert of [Tracing] Remove unnecessary memory allocation in runtime call stats. (patchset #1 id:1 of https://codereview.chromium.org/2342643004/ )

Reason for revert:
Revert because this breaks V8's roll into Chromium. ASAN complains about memory accesses in a particular unit test.

Borked roll CL:
https://codereview.chromium.org/2348833002/

Reproduce breakage with:

1, args.gn:
  v8_deprecation_warnings = true
  use_goma = true
  is_asan = true
2, ninja -C out/... content_browsertests
3, out/.../content_browsertests --gtest_filter=V8SamplingProfilerTest.*

Original issue's description:
> [Tracing] Remove unnecessary memory allocation in runtime call stats.
>
> Previously we didn't implement TRACE_STR_COPY when we write trace events to
> file, which causes us to allocate a growing independent memory chunk for dumped
> runtime call stats table. Since we now have a fully functional TRACE_STR_COPY,
> this memory allocation can be avoided, this patch removes it.
>
> BUG=v8:5089
>
> Committed: https://crrev.com/e1997bb7d780d12e3a89078e8dd652dcf1d90039
> Cr-Commit-Position: refs/heads/master@{#39462}

TBR=cbruni@chromium.org,fmeawad@chromium.org,lpy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5089

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

crrev.com/2339933002 and crrev.com/2314663002 were overlapping, so
this slipped through the cracks.

R=jochen@chromium.org
BUG=v8:4947, chromium:646794

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

Adds a fast path for loading DYNAMIC_LOCAL variables, which are lookup
variables that can be context loaded, without calling the runtime, as
long as there was no context extension by a sloppy eval along their
context chain.

BUG=v8:5263

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

The predicate in question should only trigger once and hence the stack
height should not be updated incrementally. This puts checks into place
ensuring this holds.

R=bmeurer@chromium.org

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

Revert of Preparse inner functions. (patchset #23 id:440001 of https://codereview.chromium.org/2322243002/ )

Reason for revert:
This approach is not good - breaks when we recompile.

Original issue's description:
> Preparse inner functions.
>
> This is an overly pessimistic approach where PreParser only keeps
> track of unresolved variables, but doesn't declare anything. This
> will result in context-allocating variables in the outer function
> unnecessarily, if the variable names clash with variable names
> used by the inner function (even if the variables are not the
> same). However, we have been unable to prove that this approach
> wouldn't be good enough for the practical purposes.
>
> Committed: https://crrev.com/e1341ca8fa486bb2c9e4236672a64ec7756a164d
> Cr-Commit-Position: refs/heads/master@{#39469}

TBR=adamk@chromium.org,vogelheim@chromium.org,nikolaos@chromium.org,nednguyen@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

In ignition, arguments to function calls and function constructors are
pushed onto the stack before calling the function. It is required to check
that stack does not overflow when pushing the arguments.

BUG=v8:4280
LOG=N

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

This is an overly pessimistic approach where PreParser only keeps
track of unresolved variables, but doesn't declare anything. This
will result in context-allocating variables in the outer function
unnecessarily, if the variable names clash with variable names
used by the inner function (even if the variables are not the
same). However, we have been unable to prove that this approach
wouldn't be good enough for the practical purposes.

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

During feedback typing (in SimplifiedLowering) we might be able to
constant-fold a bunch of ObjectIs<Type> predicates, i.e. because we
took type feedback on the input or we narrowed the type of a Phi
because of type feedback.

R=mvstanton@chromium.org
BUG=v8:5267,v8:5270

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

This patch moves the following parsing method to ParserBase:

- ParseTryStatement

R=adamk@chromium.org, marja@chromium.org
BUG=
LOG=N

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

This ensures that {Compiler::EnsureBytecode} fails gracefully in case
the --ignition-filter flag prevents generation of bytecode for a certain
set of functions. This can be triggered via inlining.

R=rmcilroy@chromium.org

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

In release mode, statements like:

    var i;
    for (i of [0]) { let j; debugger; }

would end up with one more block scope than in the debug modes.

R=adamk@chromium.org, marja@chromium.org
BUG=
LOG=N

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

- Smaller, more consistent streams API (Advance, Back, pos, Seek)
- Remove implementations from the header, in favor of creation functions.

Observe:
- Performance:
  - All Utf16CharacterStream methods have an inlinable V8_LIKELY w/ a
    body of only a few instructions. I expect most calls to end up there.
  - There used to be performance problems w/ bookmarking, particularly
    with copying too much data on SetBookmark w/ UTF-8 streaming streams.
    All those copies are gone.
  - The old streaming streams implementation used to copy data even for
    2-byte input. It no longer does.
  - The only remaining 'slow' method is the Seek(.) slow case for utf-8
    streaming streams. I don't expect this to be called a lot; and even if,
    I expect it to be offset by the gains in the (vastly more frequent)
    calls to the other methods or the 'fast path'.
  - If it still bothers us, there are several ways to speed it up.
- API & code cleanliness:
  - I want to remove the 'old' API in a follow-up CL, which should mostly
    delete code, or replace it 1:1.
  - In a 2nd follow-up I want to delete much of the UTF-8 handling in Blink
    for streaming streams.
  - The "bookmark" is now always implemented (and mostly very fast), so we
    should be able to use it for more things.
- Testing & correctness:
  - The unit tests now cover all stream implementations,
    and are pretty good and triggering all the edge cases.
  - Vastly more DCHECKs of the invariants.

BUG=v8:4947

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

Ensure we can serialize a wasm compiled module even after it was
instantiated a few times.

BUG=

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

Previously we didn't implement TRACE_STR_COPY when we write trace events to
file, which causes us to allocate a growing independent memory chunk for dumped
runtime call stats table. Since we now have a fully functional TRACE_STR_COPY,
this memory allocation can be avoided, this patch removes it.

BUG=v8:5089

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

Rolling v8/build to 3f47a5e106127ae4e2567d64c615dc706054c819

Rolling v8/tools/clang to bd7e80b254a93d0a5cd8ecb994e47b1c827e253c

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

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

This is one part of a WIP implementation of the stage-2 proposal to add
fields to classes: https://github.com/tc39/proposal-class-public-fields

See design doc:
https://docs.google.com/document/d/1WRtNm3ZLNJT1WVr8aq4RJuByYgfuAFAhj20LwTW6JVE/

This adds the desugaring logic to the parser. It isn't usable without
the (forthcoming) backend changes.

BUG=v8:5367

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

This is one part of a WIP implementation of the stage-2 proposal to add
fields to classes: https://github.com/tc39/proposal-class-public-fields

See design doc:
https://docs.google.com/document/d/1WRtNm3ZLNJT1WVr8aq4RJuByYgfuAFAhj20LwTW6JVE/

This adds support for parsing fields in classes, including
infrastructure. In particular, it adds:
* Two booleans on function literal AST nodes
* Two compiler hints on SharedFunctionInfos representing said bools
* A new type of ClassLiteralProperty, FIELD
* Parser support for the syntax
* Syntax tests
* A flag to enable it.

Currently the fields are parsed and then droppped. Subsequent
patches will add semantics, mostly by desugaring in the parser and
the remainder in the non-crankshaft backends.

BUG=v8:5367

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

Previously, macro like PREPARE_FOR_EXECUTION_WITH_CALLBACK will end up calling
LOG_API, where we create a runtime call timer scope when we enable tracing with
runtime call stats, however since the flag will be enabled after calling
TRACE_EVENT_CALL_STATS_SCOPED, this will end up with incorrect timestamp. Thus,
we introduce a new macro
PREPARE_FOR_EXECUTION_WITH_CONTEXT_IN_RUNTIME_CALL_STATS_SCOPE, which will call
TRACE_EVENT_CALL_STATS_SCOPED inside it.

BUG=v8:5089

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

We don't need the context anymore for parsing, the scope info chain is
enough.

BUG=v8:5215
R=marja@chromium.org,jgruber@chromium.org,mstarzinger@chromium.org

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

Reland of Put RegExp js code in strict mode (patchset #2 id:20001 of https://codereview.chromium.or… (patchset #2 id:20001 of https://codereview.chromium.org/2112713003/ )

Reason for revert:
With fixes for frozen RegExps in https://codereview.chromium.org/2339443002 , it should be web-compatible to put RegExps in strict mode again, per spec.

Original issue's description:
> Revert of Put RegExp js code in strict mode (patchset #2 id:20001 of https://codereview.chromium.org/1776883005/ )
>
> Reason for revert:
> Found to break SAP Web IDE, and these semantics are not shipped in any other browser.
> Revert to legacy semantics while assessing web compatibility.
>
> BUG=chromium:624318
>
> Original issue's description:
> > Put RegExp js code in strict mode
> >
> > src/js/regexp.js was one of the few files that was left in sloppy
> > mode. The ES2017 draft specification requires that writes to
> > lastIndex throw when the property is non-writable, and test262
> > tests enforce this behavior. This patch puts that file in strict
> > mode.
> >
> > BUG=v8:4504
> > R=yangguo@chromium.org
> > LOG=Y
> >
> > Committed: https://crrev.com/80b1b2a45bbd9bf3d08e4e6516acfaaa8f438213
> > Cr-Commit-Position: refs/heads/master@{#34801}
>
> TBR=yangguo@chromium.org,adamk@chromium.org
>
> Committed: https://crrev.com/34880eb3dcf7492d44c0a3b45b6c888189f2c3c3
> Cr-Commit-Position: refs/heads/master@{#37449}

TBR=adamk@chromium.org,yangguo@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:624318

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

This was one of the paths inside StackGuard that lacked a runtime counter,
making it hard to assess what was going on.

BUG=

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

There is no zero length array usage in inspector codebase. We can safely remove template specialization.

It was reverted to revert another patch and is good by itself.

BUG=chromium:635948
TBR=jochen@chromium.org

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

BUG=chromium:635948
R=dgozman@chromium.org,alph@chromium.org

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

To avoid a dependency on the heap during parsing, we only create a scope chain
without linking to the associated ScopeInfo objects before parsing. This is
enough to avoid special cases during parsing of arrow functions / eval.

Looking at the outer scope's variables during parsing was only needed for hosting
sloppy block functions inside eval. To be able to do this now, we hoist for the
outer-most eval scope after parsing, in DeclarationScope::Analyze.

DeclarationScope::Analyze is also where we replace the outer scope chain with the
fully deserialized version, so variables can be resolved.

Also, this unifies background and foreground thread parsing, as we don't have to
worry about ScopeInfos getting accessed before we're back on the main thread.

BUG=v8:5215
R=verwaest@chromium.org,marja@chromium.org,adamk@chromium.org

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

All parameters passed by reference must be labeled const.
If the object is mutable, then we pass by pointer.

BUG=

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

We used to intercept function definitions, but not declarations.
GenericNamedPropertySetterCallback now also intercepts function declarations.

For definitions, we call DeclareGlobal and then InitializeVarGlobal. For
declarations, we never call InitializeVarGlobal, thus we must check for
interceptors in DeclareGlobal.

If the semantics of a redeclaration are wrong, e.g., redeclaring a read-only
property, an exception is thrown independent of whether an interceptor is
installed. Usually, i.e., not during a declaration, we only throw if
the call is not successfully intercepted.

BUG=v8:5375

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

This CL implements the throw wasm opcode. This is a pre-requisite for
implementing try-catches in wasm.

BUG=

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

This handles the case where generating bytecode for inlining purposes
causes a stack overflow. We just abort inlining but also need to clear
pending exceptions.

R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-647217
BUG=chromium:647217

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

R=machenbach@chromium.org
BUG=

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

Port c7d7ca36

Original commit message:

    Add a notion of "invocation count" to the baseline compilers, which
    increment a special slot in the TypeFeedbackVector for each invocation
    of a given function (the optimized code doesn't currently collect this
    information).

    Use this invocation count to relativize the call counts on the call
    sites within the function, so that the inlining heuristic has a view
    of relative importance of a call site rather than some absolute numbers
    with unclear meaning for the current function. Also apply the call site
    frequency as a factor to all frequencies in the inlinee by passing this
    to the graph builders so that the importance of a call site in an
    inlinee is relative to the topmost optimized function.

    Note that all functions that neither have literals nor need type
    feedback slots will share a single invocation count cell in the
    canonical empty type feedback vector, so their invocation count is
    meaningless, but that doesn't matter since we only use the invocation
    count to relativize call counts within the function, which we only have
    if we have at least one type feedback vector (the CallIC slot).

    See the design document for additional details on this change:
    https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8

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

BUG=v8:5267,v8:5372
LOG=N

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

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

The semantics of the {BailoutId} representing an OSR entry point is
different between the interpreter and the full code generator. These
semantics are hard-coded in various graph builders. We need to ensure
that the correct graph builder is chosen for OSR compilations.

R=rmcilroy@chromium.org
TEST=mjsunit/regress/regress-5380
BUG=v8:5380

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

Ignition requires that objects which will be inserted into the
constant pool are canonicalized (to enable off-thread bytecode
generation). We created a CanonicalizeHandleScope across parse/compile
however this impacts performance (~5-8% on CodeLoad).

Now we localize the CanonicalHandleScope to only the parse /
internalization and renumbering phases where objects are created which
could end up in the constant array pool. This seems to address
the performance regression.

BUG=v8:5203,chromium:634953

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

Revert of [heap] Decouple old generation allocation limit from external memory. (patchset #1 id:1 of https://codereview.chromium.org/2329993002/ )

Reason for revert:
Regressions in telemetry benchmarks:
crbug.com/646819.

Original issue's description:
> [heap] Decouple old generation allocation limit from external memory.
>
> We check for external memory limit in Heap::ReportExternalMemoryPressure.
>
> BUG=chromium:616434
>
> Committed: https://crrev.com/672d079ccba686019fa1457c83b42c2e692ef88b
> Cr-Commit-Position: refs/heads/master@{#39374}

TBR=hpayer@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:616434

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

When zeroing a floating point stack slot, store the zero register directly,
rather than storing zero moved to an FP register.

BUG=

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

R=titzer@chromium.org

BUG=chromium:647027

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

This is a first implementation of inlining into graphs that have been
created using the {BytecodeGraphBuilder}. Note that inlining sticks to
graphs of the same kind, we only ever inline AstGraph into AstGraph or
BytecodeGraph into BytecodeGraph, no mixed inlining.

R=bmeurer@chromium.org,rmcilroy@chromium.org
TEST=cctest/test-run-inlining
BUG=v8:5251

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