Add a new bytecode to create a function context. The handler inlines
FastNewFunctionContextStub.

BUG=v8:4280
LOG=n

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

LOG=N
BUG=V8:5187

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

So far we treated SignedSmall and Signed32 feedback the same for number
operations. However it would be beneficial to generate (a lot) less code
if we only do a Smi check on the inputs instead of doing the full Smi +
HeapNumber + conversion check that we need to do for Signed32 feedback.

R=epertoso@chromium.org
BUG=v8:4583

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

The helper class in question is no longer needed now that frame states
representing the "before" state is not attached to nodes anymore. They
are represented by appropriate {Checkpoint} nodes in the graph now.

R=bmeurer@chromium.org
BUG=v8:5021

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

The MachineOperatorReducer was only reducing word32 expressions of the type x << y | x >>> (32 - y) (and variants) to the equivalent Word32Ror. This CL applies the same pattern-matching logic to Word32Xor.

BUG=

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

Move all the typing rules for unary and binary number operations to the
OperationTyper and use them for both the regular Typer as well as the
retyper that runs as part of SimplifiedLowering.

R=epertoso@chromium.org

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

This completely removes the ability from nodes to point directly to the
frame state representing their eager bailout point. All nodes now either
have zero or one frame state inputs. These frame states can by now be
found via checkpoints in the graph.

R=bmeurer@chromium.org
BUG=v8:5021

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

This removes the frame state input representing the before-state from
nodes having any int32 bitwise operator. Lowering that inserts number
conversions of the inputs has to be disabled when deoptimization is
enabled, because the frame state layout is no longer known.

R=epertoso@chromium.org
BUG=v8:5021,v8:4746

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

  port a7581443 (r38231)

  original commit message:
  When we narrow a signed32 comparison to uint8 or uint16 representation,
  we also need to change the condition to unsigned comparisons otherwise
  the comparison will be done on int16/int8 which interprets the narrowed
  bits wrong.

BUG=

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

Infer a more precise type even in case where NaN and/or -0 is a possible
outcome of the operation, and use this more precise type to improve code
generation for the modulus itself by trying harder to stick to Word32
operations instead of going to Float64, and also optimize the pattern
where we compare the output of x % y to some non-zero integer constant
K, in which case we can truncate the output of x % y to Word32 if the
type of x % y is Signed32/Unsigned32 \/ NaN \/ MinusZero, as NaN and
MinusZero will both be truncated to zero, which cannot match the non
zero constant K.

R=jarin@chromium.org

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

BUG=v8:5162
R=bmeurer@chromium.org, cbruni@chromium.org

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

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

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

This completely removes translation of exception handler predictions
from the graph IR. We now rely on the runtime using deoptimization
infomation via {FrameSummary} for predictions in optimized code.

R=bmeurer@chromium.org

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

BUG=

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

This is a simple cleanup to use the recently added CheckMaps operator
instead of the hand-crafted map check sequence.

R=epertoso@chromium.org

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

We cannot just blindly make a representation selection for Phi or Select
based on the truncations, but we also need to consider the type of the
inputs (or actually of the Phi/Select node itself). We can only use
Word32 representation based on Word32 truncation if the inputs are
Number or Oddball, same for Float64.

R=epertoso@chromium.org
BUG=v8:5255

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

This adds support for lowering keyed access to JSTypedArray objects to
element loads and stores instead of IC calls. There's still a lot of
room for improvement, but the improvements can be done incrementally
later.

We add a dedicated UnsafePointerAdd operator, which sits in the effect
chain, and does the (GC invisible) computation of addresses that are
potentially inside HeapObjects. Also there's now a dedicated Retain
operator, which ensures that we retain a certain tagged value, which is
necessary to ensure that we keep a JSArrayBuffer alive as long as we
might still potentially access elements in its backing store.

R=epertoso@chromium.org

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

When we narrow a signed32 comparison to uint8 or uint16 representation,
we also need to change the condition to unsigned comparisons otherwise
the comparison will be done on int16/int8 which interprets the narrowed
bits wrong.

R=epertoso@chromium.org
BUG=v8:5254

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

Revert of [builtins] implement Array.prototype.includes in TurboFan (patchset #20 id:380001 of https://codereview.chromium.org/2146293003/ )

Reason for revert:
[Sheriff] Breaks:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Arm%20-%20builder/builds/2592

Original issue's description:
> [builtins] implement Array.prototype.includes in TurboFan
>
> BUG=v8:5162
> R=bmeurer@chromium.org, ishell@chromium.org
>
> Committed: https://crrev.com/a488b5d8eb111a4883dc400bd826d079420edd68
> Cr-Commit-Position: refs/heads/master@{#38223}

TBR=adamk@chromium.org,bmeurer@chromium.org,cbruni@chromium.org,danno@chromium.org,ishell@chromium.org,littledan@chromium.org,caitp@igalia.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5162

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

BUG=v8:5162
R=bmeurer@chromium.org, ishell@chromium.org

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

The initialization of static variables that were used originally caused
a data race because multiple threads tried to initialize the variables
at the same time. The use of a LazyInstance guarantees that the
variables get initialized exactly once.

The same problem also existed in c-linkage.cc. There I fixed the problem
by using a local variable instead of a static variable.

BUG=v8:5242
R=titzer@chromium.org

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

This will enable the interpreter to add a bytecode and use the stub.

BUG=v8:4280
LOG=n

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

R=jarin@chromium.org

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

This adds initial support to inline a couple of the ArrayBuffer view
accessors like %TypeArray%.prototype.length and.
DataView.prototype.byteLength.

R=epertoso@chromium.org

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

This removes the frame state input representing the before-state from
nodes having any shift operator. Any lowering that woult insert number
conversions of the inputs has already been disabled when deoptimization
is enabled, because the frame state layout is no longer known.

R=epertoso@chromium.org
BUG=v8:5021

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

Allow inlining of getters and setters into TurboFan optimized code.
This just adds the basic machinery required to essentially inline
the setter and getter dispatch code for the (keyed) load/store ICs.
There'll be follow up CLs to also actually inline some of the interesting
accessor functions itself, like the byteLength and friends for the
TypedArrays.

R=jarin@chromium.org

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

This introduces a bunch of new tests that test various aspects of
accessor inlining in TurboFan (without the actual inlining), and does
the appropriate fixes to the AstGraphBuilder. The actual inlining CL
will land separately (so we don't need to revert the tests and fixes
if the accessor CL has to be reverted).

R=jarin@chromium.org

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

We have a similar optimization for unchecked integer modulus, which
already boosted some asm.js use cases. Now this optimization is almost
as effcient as Crankshafts known power of 2 right hand side optimization
for modulus, but it can still deal with any rhs (except 0), and doesn't
require the interpreter to also collect known power of two rhs feedback.

R=jarin@chromium.org

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

This commit fixes wasm little-endian load issue on big-endian platform
by introducing reverse byte operation immediately after a load.

R=bmeurer@chromium.org, titzer@chromium.org
BUG=

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

This gets rid of the Star bytecodes that were always dispatched to from
ToObject.
ToObject now outputs to register instead of to the accumulator and
ForInPrepare gets the receiver object from an input register.

BUG=v8:4820
LOG=n

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

Drive-by fix: actually match the hint in the IsSpeculativeBinopMatcher.

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

So far we always create explicit control flow for map checks during
JSNativeContextSpecialization, or in the monomorphic case we used a
CheckIf combined with a map comparison. In either case we cannot
currently effectively utilize the map check information during load
elimination to optimize (polymorphic) map checks and elements kind
transitions.

With the introduction of CheckMaps, we can now start optimizing map
checks in a more effective fashion. This CL doesn't change anything
in that direction yet, but merely changes the fundamental mechanism.

This also removes the stable map optimization from the Typer, where
it was always a bit odd, and puts it into the typed lowering and
the native context specialization instead.

R=epertoso@chromium.org
BUG=v8:4930,v8:5141

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

R=mvstanton@chromium.org

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

The keyed load/store lowering is too aggressive when it comes to element
vs. property access. If we cannot find a cached name on the IC we
automatically assume that it's an element access, i.e. we assume that
the key that is passed to the keyed access must be a valid array index
then. But this is not true for megamorphic keyed load/store ICs, which
do not have a cached name (because the IC saw different names), and thus
use a different mechanism to indicate that it's a non-element access.

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

- Changes register allocation to only use even numbered registers on Arm.
- Turns on float32 testing in test-gap-resolver.cc.

This is effectively a revert of:
https://codereview.chromium.org/2086653003/

LOG=N
BUG=V8:4124, V8:5202

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

In native context specialization, we attempt to use map-based feedback to do optimized named and element loads and stores. Tragically, it could happen that any maps we encounter for a load have been deprecated. The right thing to do here is reoptimize later, let the IC subsystem update the map.

BUG=

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

Split the monster methods in JSNativeContextSpecialization into smaller
ones, adding appropriate helpers. Improve the condition checking for
strings and numbers using CheckString/CheckNumber when applicable. Also
try to merge compatible PropertyAccessInfos, to avoid running into the
polymorphic case whenever possible.

Drive-by-fix: Don't try to resurrect dead nodes during LoadElimination.
With the improve code generation for monomorphic loads, we seem to
trigger the dead node resurrection.

R=epertoso@chromium.org
BUG=v8:4930,v8:5141

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

  port ba092fb0 (r37971)

  original commit message:
  So far we don't have a useful way to inline Math.max or Math.min in
  TurboFan optimized code. This adds new operators NumberMax and NumberMin
  and changes the Float64Max/Float64Min operators to have JavaScript
  semantics instead of the C++ semantics that it had previously.

  This also removes support for recognizing the tenary case in the
  CommonOperatorReducer, since that doesn't seem to have any positive
  impact (and actually doesn't show up in regular JavaScript, where
  people use Math.max/Math.min instead).

BUG=

  Drive-by-fix: Also nuke the unused Float32Max/Float32Min operators.
Review-Url: https://codereview.chromium.org/2187463005

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

If the input to a CheckString is already a String, then the check
is redundant.

R=epertoso@chromium.org

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

This patch updates internal data structures used by V8 to support
multiple indirect function tables (WebAssembly/design#682). But, since
this feature is post-MVP, the functionality is not directly exposed and
parsing/generation of WebAssembly is left unchanged. Nevertheless, it
is being used in an experiment to implement fine-grained control flow
integrity based on C/C++ types.

BUG=

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