Infer exact types for the various Date getter builtins, and also inline
the Date.prototype.getTime() builtin, which just returns the Date value
and thus doesn't need to check the cache stamp.

R=epertoso@chromium.org

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

Drop the typing rules for the machine operators and replace them
with UNREACHABLE. These typing rules were never correct and there's
also no need to have those rules at all.

Drive-by-fix: Remove the extremely annoying test-simplified-lowering.cc
file, which is not very useful, but consumes a large amount of time to
keep it compiling and passing. Instead we should introduce appropriate
tests for the SimplifiedLowering that also test something meaningful
w/o just cementing the implementation.

R=jarin@chromium.org
BUG=v8:5267

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

These JavaScript operators were special hacks to ensure that we always
operate on Smis for the magic for-in index variable, but this never
really worked in the OSR case, because the OsrValue for the index
variable didn't have the proper information (that we have for the
JSForInPrepare in the non-OSR case).

Now that we have loop induction variable analysis and binary operation
hints, we can just use JSLessThan and JSAdd instead with appropriate
Smi hints, which handle the OSR case by inserting Smi checks (that are
always true). Thanks to OSR deconstruction and loop peeling these Smi
checks will be hoisted so they don't hurt the OSR case too much.

Drive-by-change: Rename the ForInDone bytecode to ForInContinue, since
we have to lower it to JSLessThan to get the loop induction variable
goodness.

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

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

R=jarin@chromium.org
BUG=v8:5267

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

Typing these operators should never happen and doesn't make any sense
at all.

R=jarin@chromium.org

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

For asm.js we now have a dedicated AsmTyper, that uses it's own type
system (which is tailored towards asm.js), and so we don't need the
special asm.js types anymore in the TypeCache. This also moves the
TypeCache into the src/compiler directory, because it doesn't make
sense to use outside anyways.

TBR=ahaas@chromium.org
R=jarin@chromium.org
BUG=v8:5267

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

Using the dedicated simplified operator we are able to eliminate
redundant neuterung checks as long as there is no call in the
effect chain. This yields a nice speed up for the Octane Mandreel
benchmark (and TypedArray-heavy workloads in general).

R=jarin@chromium.org
BUG=v8:5267

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

This reverts commit a55fdb1e, relands
https://codereview.chromium.org/2266823002/.

BUG=chromium:638132

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

Revert of [turbofan] Insert dummy values when changing from None type. (patchset #5 id:80001 of https://codereview.chromium.org/2266823002/ )

Reason for revert:
Octane/Mandreel aborts with an exception now:

TypeError: __FUNCTION_TABLE__[(r2 >> 2)] is not a function

Original issue's description:
> [turbofan] Insert dummy values when changing from None type.
>
> Currently we choose the MachineRepresentation::kNone representation for
> values of Type::None, and when converting values from the kNone representation
> we use "impossible" conversions that will crash at runtime. This
> assumes that the impossible conversions should never be hit (the only
> way to produce the impossible values is to perform an always-failing
> runtime check on a value, such as Smi-checking a string). Note that
> this assumes that the runtime check is executed before the impossible
> convesrion.
>
> Introducing BitwiseOr type feedback broke this in two ways:
>
> - we always pick Word32 representation for bitwise-or, so the
>   impossible conversion does not trigger (it only triggers with
>   None representation), and we could end up with unsupported
>   conversions from Word32.
>
> - even if we inserted impossible conversions, they are pure conversions.
>   Since untagging, bitwise-or operations are also pure, we could hoist
>   all these before the smi check of the inputs and we could hit the
>   impossible conversions before we get to the smi check.
>
> This CL addresses this by just providing dummy values for conversions
> from the Type::None type. It also removes the impossible-to-* conversions.
>
> BUG=chromium:638132
>
> Committed: https://crrev.com/c83b21ab755f1420b6da85b3ff43d7e96ead9bbe
> Cr-Commit-Position: refs/heads/master@{#38883}

TBR=mstarzinger@chromium.org,jarin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:638132

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

Currently we choose the MachineRepresentation::kNone representation for
values of Type::None, and when converting values from the kNone representation
we use "impossible" conversions that will crash at runtime. This
assumes that the impossible conversions should never be hit (the only
way to produce the impossible values is to perform an always-failing
runtime check on a value, such as Smi-checking a string). Note that
this assumes that the runtime check is executed before the impossible
convesrion.

Introducing BitwiseOr type feedback broke this in two ways:

- we always pick Word32 representation for bitwise-or, so the
  impossible conversion does not trigger (it only triggers with
  None representation), and we could end up with unsupported
  conversions from Word32.

- even if we inserted impossible conversions, they are pure conversions.
  Since untagging, bitwise-or operations are also pure, we could hoist
  all these before the smi check of the inputs and we could hit the
  impossible conversions before we get to the smi check.

This CL addresses this by just providing dummy values for conversions
from the Type::None type. It also removes the impossible-to-* conversions.

BUG=chromium:638132

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

The new operators are implemented similar to the Float64(Max|Min) which
already exist. The purpose of the new operators is the implementation
of the F32Max and F32Min instructions in WebAssembly.

R=titzer@chromium.org, v8-arm-ports@googlegroups.com, v8-mips-ports@googlegroups.com

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

This detects loops with integer decrements.

Drive-by fix: Add lower bounds to lower_bounds
zone vector instead of upper_bounds.

BUG=

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

If the intersection of the types of nodes a and b is empty, then there's
no way that a and b could ever refer to the same object, so we can use
that information for alias analysis.

Drive-by-fix: Improve use of types to enable typed alias analysis to
become more effective. Also fix an ASAN issue uncovered by this CL.

R=jarin@chromium.org

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

Separate ConvertTaggedHoleToUndefined and CheckTaggedHole into two
separate operators, where the former is pure and just turns into
trivial control flow in the EffectControlLinearizer.

R=jarin@chromium.org

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

Also eliminate redundant CheckBounds node during SimplifiedLowering if
we can prove that the index is within the [0.0, length[ range.

R=epertoso@chromium.org

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

Sanitize the typing rules for the various supported Math builtins, and
add appropriate typing rules for various Number, String, Object and global
builtins as well.

R=franzih@chromium.org

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

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

This CL changes the semantics of FloatXXSub to match the semantics of
the semantics of FloatXXSubPreserveNan. Therefore there is no need
anymore for the FloatXXSubPreserveNan operators.

The optimizations in VisitFloatXXSub which are removed in this CL have
already been moved to machine-operator-reducer.cc in
https://codereview.chromium.org/2226663002

R=bmeurer@chromium.org

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

Introduce a dedicated MaybeGrowFastElements simplified operator, which
tries to grow a fast elements backing store for a given element that
should be added to an array/object. Use that to lower a growing keyed
store to a sequence of

 1) check index is a valid array index,
 2) check stored value,
 3) maybe grow elements backing store (and deoptimize if it would
    normalize), and
 4) store the actual element.

The actual growing is done by two dedicated GrowFastDoubleElements
and GrowFastSmiOrObjectElements builtins, which are very similar to
the GrowArrayElementsStub that is used by Crankshaft.

Drive-by-fix: Turn CopyFixedArray into CopyFastSmiOrObjectElements
builtin, similar to the new growing builtins, so we don't need to
inline the store+write barrier for the elements into all optimized
code objects anymore.

Also fix a bug in the OperationTyper for NumberSilenceNaN, which was
triggered by this change.

BUG=v8:5272

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

This extends JSNativeContextSpecialization with support for stores to
fast object/smi element backing stores that are marked as copy-on-write.
In this case we first call the CopyFixedArray builtin to take a copy of
the elements backing store, and then store the new elements back to the
object, and finally perform the actual element store.

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

Committed: https://crrev.com/ac98ad22f049a59c48387f1bab1590f135d219c6
Review-Url: https://codereview.chromium.org/2218703003
Cr-Original-Commit-Position: refs/heads/master@{#38370}
Cr-Commit-Position: refs/heads/master@{#38392}

If we infer loop variable bounds, we need to insert a type rename node
(sigma) to make sure that simplified lowering can choose representations
consistently.

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

Revert of [turbofan] Add support for copy-on-write element stores. (patchset #2 id:20001 of https://codereview.chromium.org/2218703003/ )

Reason for revert:
Breaks tree?

Original issue's description:
> [turbofan] Add support for copy-on-write element stores.
>
> This extends JSNativeContextSpecialization with support for stores to
> fast object/smi element backing stores that are marked as copy-on-write.
> In this case we first call the CopyFixedArray builtin to take a copy of
> the elements backing store, and then store the new elements back to the
> object, and finally perform the actual element store.
>
> R=epertoso@chromium.org
> BUG=v8:4470
>
> Committed: https://crrev.com/ac98ad22f049a59c48387f1bab1590f135d219c6
> Cr-Commit-Position: refs/heads/master@{#38370}

TBR=epertoso@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4470

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

This extends JSNativeContextSpecialization with support for stores to
fast object/smi element backing stores that are marked as copy-on-write.
In this case we first call the CopyFixedArray builtin to take a copy of
the elements backing store, and then store the new elements back to the
object, and finally perform the actual element store.

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

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

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}

BUG=

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

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}

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}

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}

Introduce an appropriate StringCharCodeAt simplified operator and use
that to optimize the String.prototype.charCodeAt/.charAt builtins.

R=epertoso@chromium.org

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

The new phase will detect loop variable, infer bounds and bake them into
the type.

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

Introduce the CheckString during native context specialization when we
have string map feedback on a LOAD_IC/STORE_IC. The CheckString
operator, just like its CheckNumber pendant, renames the input and
assigns a proper type, which we will use soon to lower access operations
on Strings, i.e. charCodeAt calls or keyed accesses.

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

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

When we eliminate nodes during truncation analysis that have no value
uses, we must make sure that we do not eliminate speculative number
operations that would have side effects depending on the inputs, i.e.
for example a SpeculativeNumberMultiply(x,y) does ToNumber(x) and
ToNumber(y) first, so if either x or y could throw an exception during
ToNumber conversion, we must not eliminate the multiplication, even if
it has no value uses (some later pass may kill the actual machine
multiplication, but the checks on the inputs have to remain still).
So we check whether both x and y are PlainPrimitive, i.e. neither
Receiver nor Symbol, which could raise exceptions for ToNumber, and
only in that case we propagate the "unusedness" of the node to its
inputs.

This also uncovered a bug with the type of Dead, which must be None,
as this represents an impossible value, so we had to fix that too.

Also the dead code removal will not work correctly for constants (i.e.
pure nodes with no value inputs), as those might be cached and hence
we might resurrect them for an unrelated node lowering during
SimplifiedLowering and only later kill the actual node (replacing its
uses with Dead), which would then also replace the new use with Dead.
So that was fixed as well. This shouldn't change anything for the
result, as unused constants automagically disappear from the graph later
on anyways.

R=yangguo@chromium.org
BUG=chromium:631318

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

BUG=chromium:630611

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

Implement UnalignedLoad and UnalignedStore optional
turbofan operators and use them in WasmCompiler for unaligned
memory access.

BUG=

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

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).

Drive-by-fix: Also nuke the unused Float32Max/Float32Min operators.

R=jarin@chromium.org

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

This is never passed to the Typer, and actually wouldn't work
anyways, since we cannot derive any meaningful types for
Parameters in JavaScript.

R=mstarzinger@chromium.org

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

Instead of wriring the elements kind transitions into the control flow
early on, we do instead put this marker into the effect chain, so that
the elements transitions are visible to the LoadElimination and can
thus be optimized properly there.

This CL itself doesn't add any of those optimizations, but just adds
the foundations to make them possible later.

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

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

This CL introduces explicit LoopExit control nodes at loop exits.
We also attach explicit value renames (LoopExitMarker) and effect
rename (LoopExitEffect) to each loop exit. This is in preparation
to loop peeling, which will replace LoopExit, LoopExitMarker and
LoopExitEffect with Merge, Phi and EffectPhi respectively.

At the moment, we insert loop exit at every return, break,
continue and locally caught throw. We do not yet handle
uncaught throws (including error throws, such as ReferenceError).

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

Typed lowering now produces SpeculativeNumberShiftLeft for JSShiftLeft if the type feedback is kSignedSmall or kSigned32.

BUG=v8:4583
LOG=n

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