The typing rule for JSCreateArguments must properly declare rest
parameters as arrays and only consider sloppy and strict arguments
objects as Type::OtherObject.

TBR=jarin@chromium.org
BUG=v8:6262,chromium:712802

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

Use Type::Array to constant-fold Array.isArray builtin based on the
value input type. Also use it to improve type based alias analysis,
where we know that stores to an object of type Array don't affect stores
to an object of type OtherObject, and vice versa.

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

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

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}

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 a dedicated operator for ToNumber(x) with feedback instead of
translating to SpeculativeNumberMultiply(x,1), which allows us to
treat the case where x is already a Number specially, ignoring the
feedback on the operator. This recovers most of the regression in
the crypto benchmark.

BUG=chromium:709398,v8:6214,v8:5267
R=jarin@chromium.org

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

This gives us more precise type information, so we can avoid some type
guards to refine the type information back.

The motivation for this is to help escape analysis by not introducing
redundant type guards (which escape analysis cannot handle yet even
though it could and should do).

Motivating example:

In the example below, the out-of-object property array for properties
fld5 and fld6 gets type Any when it is created by "o.fld5 = 5" (for
object literals, we store 4 properties in-objeca, the rest goes out
of object).

When we run load elimination for the load the out-of-object property
array (to store 6 into o.fld6), load elimination inserts TypeGuard to
enforce the Type::Internal() type. This makes escape analysis bail out
on this object, and we do not eliminate the object creation.

function f() {
  var o = {};
  o.fld1 = 1;
  o.fld2 = 2;
  o.fld3 = 3;
  o.fld4 = 4;
  o.fld5 = 5;
  o.fld6 = 6;
}

f();
f();
%OptimizeFunctionOnNextCall(f);
f();

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

Typer::Visitor::ToLength was unsound (and non-monotonic).  For instance,
if the input type was Range(2^53, 2^53+1), the result type was
Constant(2^53).  Now the result is type Constant(2^53-1).  (The result
of ToLength is guaranteed to be between 0 and 2^53-1.)

BUG=

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

This handles non-strict equality comparison operations having number
feedback during the early type-hint lowering (i.e. during graph
construction).

R=jarin@chromium.org

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

Used by ReduceJSEqualTypeOf, and will also be used to lower a new 
TestTypeof bytecode in a followup CL.

BUG=v8:5267

Change-Id: I990aa6ac8ac0b9bd01080dda1764c5bfe3a4d7cf
Reviewed-on: https://chromium-review.googlesource.com/454797Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43802}

The parser already changes all negative equality comparison operations
to their positive pendants in {ParserBase::ParseBinaryExpression}. No
other source of the Token::NE exists in the system. We can remove all
handling from the compiler and interpreter backends.

R=bmeurer@chromium.org

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

We don't need the JSStrictNotEqual operator in the compiler, because
this is never generated by the BytecodeGraphBuilder, and the code in
the AstGraphBuilder was dead code. Also remove the backing builtin
StrictNotEqual.

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

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

Following the design of https://codereview.chromium.org/2692753004, also compute the arguments length in the deoptimizer sucht that it does not have to be computed in optimized code.

R=bmeurer@chromium.org

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

We can compile a !== a and Number.isNaN(a) to ObjectIsNaN. The former is
commonly used to check for NaN, i.e. in case of equals in AngularJS.

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

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

The new NewUnmappedArgumentsElements node now takes two inputs:
- the frame holding the arguments (current frame or arguments adaptor frame)
- the length of the suffix of passed arguments to be copied into the backing store

These inputs are computed with two new node types:
ArgumentsFrame()
ArgumentsLength[formal_parameter_count,is_rest_length](Node* arguments_frame)
The node type NewRestParameterElements can now be expressed with NewUnmappedArgumentsElements and an appropriate length and is thus not needed anymore.

In escape analysis, we lower loads from the length field of NewUnmappedArgumentsElements with its length input and if we find out that no write access to the arguments elements exists, we replace element loads with direct stack access and replace the NewUnmappedArgumentsElements node with a node of the new node type ArgumentsElementsState. This corresponds to an ObjectState node and gets translated into a deoptimizer instruction to allocate the backing store. Together with the already existing deoptimizer support for the actual arguments object/rest parameters, this allows to remove all allocations for arguments objects/rest parameters in this case.
In the deoptimizer, we read the actual parameters from the stack while transforming the static deopt info into TranslatedValue objects.

If escape analysis cannot remove the backing store allocation, NewUnmappedArgumentsElements gets lo

BUG=v8:5726

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

This extends the existing typer for JS-level comparisons to also be
applied on simplified-level number comparisons. Now that nodes having
such operators are introduced early during graph construction, precise
type information has become more important.

R=jarin@chromium.org
TEST=unittests/TyperTest

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

Currently, typeof o, where o is an undetectable
callable object (such as document.all), returns 'function' if
optimised. It should, however, return 'undefined'.

This CL excludes undetectable objects from the optimization
resulting in type 'function' and renames the related code to
reflect that.

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

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

... which is used for initializing properties with non compile time values.

Currently we use StoreOwnIC only for storing properties that already exist
in the boilerplate therefore we can reuse StoreIC dispatcher.
The proper StoreOwnIC dispatcher will be implemented in a separate CL.

BUG=v8:5495, v8:4414

Change-Id: I9c33fdb8499ec5be2c7fce1ecb6ce7aa285e5844
Reviewed-on: https://chromium-review.googlesource.com/443588Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43285}

Since the empty string is canonical HeapObject now, we can use
this fact to optimize

  - strict equality comparisons with the empty string to a
    simple ReferenceEqual operation, and
  - optimize ToBoolean to avoid instance type checks completely.

Drive-by-fix: Allow InternalizedString for Type::HeapConstant
in the type system. This is safe, since InternalizedStrings
can be compared to other heap constants by reference (except
for non-InternalizedStrings, which are excluded from the
HeapConstant type).

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

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

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

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

Update type of JSForInNext to say String\/Undefined.

R=jarin@chromium.org

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

The StringIndexOf operation is pure on the JS level, but the actual stub
call must be in the effect chain later so that the Scheduler doesn't
place it inside some allocation region (The %StringIndexOf runtime
function may trigger a GC for string flattening).

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

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

Previously, when restarting a frame, we would rewrite all frames
between the debugger activation and the frame to restart to squash
them, and replace the return address with that of a builtin to
leave that rewritten frame, and restart the function by calling it.

We now simply remember the frame to drop to, and upon returning
from the debugger, we check whether to drop the frame, load the
new FP, and restart the function.

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

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

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

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

We turn a JSCallFunction node for

  f.apply(receiver, arguments)

into a JSCallForwardVarargs node, when the arguments refers to the
arguments of the outermost optimized code object, i.e. not an inlined
arguments, and the apply method refers to Function.prototype.apply,
and there's no other user of arguments except in frame states.

We also replace the arguments node in the graph with a marker for
the Deoptimizer similar to Crankshaft to make sure we don't materialize
unused arguments just for the sake of deoptimization. We plan to replace
this with a saner EscapeAnalysis based solution soon.

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

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

Add the operator in preparation for actual perf work. The operator is replaced
by the same runtime call as before, during lowering.

BUG=v8:5511

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

Let the Typer assign proper types to Map, Set, WeakMap and WeakSet
builtins. Also assign a proper type to Array.isArray, Object.assign
and Object.create.

R=yangguo@chromium.org

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

The %_ClassOf intrinsic roughly corresponds to the deprecated ES5
[[Class]] internal property, and should not be used anymore ideally.
However since we still have quite a couple of uses of this intrinsic
in the self hosted JavaScript builtins, we would tank some builtins
like Map, Set, WeakMap, WeakSet, etc. quite significantly unless we
also support this intrinsic until the builtins are all migrated to
C++/CSA builtins.

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

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

The %ClassOf runtime function and %_ClassOf intrinsics always produce an
internalized string, or Null for primitive inputs.

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

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

Properly recognize and optimize typeof in a strict/abstract equality
comparison with the string literal "object" to a check for Null or a
check of the map for Receiver instance type and non-callable.

Drive-by-fix: Also optimize typeof o === "function" somewhat, now that
we have the new types for Callable and NonCallable.

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

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

Collect Receiver feedback for abstract/strict equality in Ignition and
use it in TurboFan to optimize JSEqual and JSStrictEqual operations to
pointer equality instead of having to call Equal/StrictEqual builtins.

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

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

Add machinery to Ignition and TurboFan to collect and consume
InternalizedString feedback for abstract and strict equality
comparisons. Here we can turn the comparison into a simple
pointer equality check.

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

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

Previously String element access and String.prototype.charAt were
lowered to a subgraph StringFromCharCode(StringCharCodeAt(s, k)),
however that can be fairly expensive both runtime and compile time
wise. The dedicated StringCharAt operator is implemented via a call
to a builtin that does exactly this.

R=yangguo@chromium.org

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

This is so that a NotSuperConstructor error is thrown before evaluating the
arguments to the super constructor. Besides updating the runtime function, a
new bytecode GetSuperConstructor is introduced.

BUG=v8:5336

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

Some instructions in WebAssembly trap for some inputs, which means that the
execution is terminated and (at least at the moment) a JavaScript exception is
thrown. Examples for traps are out-of-bounds memory accesses, or integer
divisions by zero.

Without the TrapIf and TrapUnless operators trap check in WebAssembly introduces 5
TurboFan nodes (branch, if_true, if_false, trap-reason constant, trap-position
constant), in addition to the trap condition itself. Additionally, each
WebAssembly function has four TurboFan nodes (merge, effect_phi, 2 phis) whose
number of inputs is linear to the number of trap checks in the function.
Especially for functions with high numbers of trap checks we observe a
significant slowdown in compilation time, down to 0.22 MiB/s in the sqlite
benchmark instead of the average of 3 MiB/s in other benchmarks. By introducing
a TrapIf common operator only a single node is necessary per trap check, in
addition to the trap condition. Also the nodes which are shared between trap
checks (merge, effect_phi, 2 phis) would disappear. First measurements suggest a
speedup of 30-50% on average.

This CL only implements TrapIf and TrapUnless on x64. The implementation is also
hidden behind the --wasm-trap-if flag.

Please take a special look at how the source position is transfered from the
instruction selector to the code generator, and at the context that is used for
the runtime call.

R=titzer@chromium.org

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

Add the operator in preparation for actual perf work. The operator is replaced
by the same runtime call as before, during lowering.

The CallConstructWithSpreadParameters is a bit silly at the moment, but will
hold more once we add feedback.

BUG=v8:5659

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

First step towards making arguments and rest parameters optimizable by
splitting the allocations for the actual object and the elements. The
object allocations can already be escape analyzed this way, the elements
would need special support in the deoptimizer and the escape analysis,
but that can be done as a second separate step.

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

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

This introduces three new types OtherCallable, CallableProxy (and OtherProxy),
and BoundFunction to make it possible to express Callable in the Type system.
It also forces all undetectable receivers to be Callable, which matches the
use case for undetectable, namely document.all (guarded by proper checks and
tests).

It also uses these new types to properly optimize instanceof (indirectly via
OrdinaryHasInstance) based on the type of the constructor and the object. So
we are able to constant-fold certain instanceof expressions based on types
and completely avoid the builtin call.

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

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

For a couple of those Array builtins we can specify a useful type that
will help us to eliminate a couple of checks on their outputs.

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

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

Assign types to the remaining builtins on the String.prototype where we
know a meaningful type, i.e. where the type is not dependent on some
callable function that is pass or loaded.

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

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