Checked integer division and modulus can be done more efficiently
if we know that the inputs are in Unsigned32 range.

Drive-by-fix: Replace the TypeCheckKind on NodeInfo by a proper
restriction type, and thread the feedback type through binary
Number operations similar to what we do for their speculative
versions. Also deal with Unsigned32 inputs for integer multiplication.

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

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

This removes the checking for use-def and def-use chain links from the
graph verification. Presence of such links can only be violated by a bug
in the actual {Node} implementation itself. That container class is also
covered by unit tests.

The verification in question was useful in the early days when the graph
implementation itself was prone to bugs. By now it has stabilized and
spending O(n^2) time during graph verification is too wasteful to still
be considered a reasonable trade-off.

R=jarin@chromium.org
TEST=unittests/NodeTest.*

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

The PlainPrimitiveToNumber operator performs a superset of the operations
previously performed by the BooleanToNumber and StringToNumber operators,
so we can just use the special lowering rules for PlainPrimitiveToNumber
based on the input type and get rid of the specialized operators.

R=jarin@chromium.org

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

Consume Smi/Signed32 feedback for division and modulus and introduce
appropriate checked operators. This is especially important for modulus
where the Float64Mod operator is significantly slower than Int32Mod on
most platforms. For division it's mostly important to propagate
integerness, i.e. to avoid follow-up conversions between float and
int32.

Drive-by-fix: Use Int32Mod for the ModulusStub (and the bytecode handler)
when the inputs are both Smi.

R=jarin@chromium.org

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

Import fdlibm versions of acos, acosh, asin and asinh, which are more
precise and produce the same result across platforms (we were using
libm versions for asin and acos so far, where both speed and precision
depended on the operating system so far). Introduce appropriate TurboFan
operators for these functions and use them both for inlining and for the
generic builtin.

Also migrate the Math.imul and Math.fround builtins to TurboFan builtins
to ensure that their behavior is always exactly the same as the inlined
TurboFan version (i.e. C++ truncation semantics for double to float
don't necessarily meet the JavaScript semantics).

For completeness, also migrate Math.sign, which can even get some nice
love in TurboFan.

Drive-by-fix: Some alpha-sorting on the Math related functions, and
cleanup the list of Math intrinsics that we have to export via the
native context currently.

BUG=v8:3266,v8:3496,v8:3509,v8:3952,v8:5169,v8:5170,v8:5171,v8:5172
TBR=rossberg@chromium.org
R=franzih@chromium.org

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

BUG=v8:5086

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

This adds a new CheckIf operator and changes all direct uses of
DeoptimizeIf and DeoptimizeUnless on the JavaScript level to use
CheckIf (or one of the more concrete check operators) instead.
This way we do not depend on particular frame states, but the
effect/control linearizer will assign an appropriate frame
state instead.

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

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

The only real use case left for TypeGuard was the renaming inside the
LoadElimination, but this case only occurs in dead code (guarded by a
previous Check), so it's not relevant, and we can drop the TypeGuard
operator completely.

R=jarin@chromium.org

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

We use CheckNumber to guard values as being proper numbers, i.e. if the
input value is anything but a Number, we deoptimize. This follows the
existing effect/control linearization magic that we already use for the
other checks.

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

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

Introduce a new machine operator Float64Pow that for now is backed by
the existing MathPowStub to start the unification of Math.pow, and at
the same time address the main performance issue that TurboFan still has
with the imaging-darkroom benchmark in Kraken.

Also migrate the Math.pow builtin itself to a TurboFan builtin and
remove a few hundred lines of hand-written platform code for special
handling of the fullcodegen Math.pow version.

BUG=v8:3599,v8:5086,v8:5157

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

R=adamk@chromium.org
BUG=

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

Add NumberAbs operator to implement an inline version of Math.abs, that
can be optimized and eliminated. We don't use any speculation here, but
for now stick to the information we can infer (this way we avoid the
inherent deopt loops that Crankshaft has around Math.abs).

CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
R=jarin@chromium.org
BUG=v8:5086

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

Add control dependencies to Projection and Int32Add/SubWithOverflow
operators, to prevent the scheduler from moving the Projection nodes
into the wrong place. This way the instruction selection can combine
the Int32Add/SubWithOverflow operations with the DeoptimizeIf and/or
DeoptimizeUnless nodes. This needs new operators CheckedInt32Add and
CheckedInt32Sub so that we can delay the actual lowering until the
effect/control linearizer.

This also makes CheckIf operator obsolete, so we can drop it.

R=jarin@chromium.org

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

These are used to check for Smi or HeapObject, and we use them
appropriately in JSNativeContextSpecialization, so we don't need
to introduce dependencies on concrete control flow and/or concrete
frame states.

They will be optimized by a proper check elimination reducer,
which will be added in a separate CL.

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

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

Revert of [turbofan] Introduce CheckUnless. (patchset #1 id:1 of https://codereview.chromium.org/2080113002/ )

Reason for revert:
[Sheriff] Speculative revert: Seems to lead to devtools crashes:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Win/builds/5259

Original issue's description:
> [turbofan] Introduce CheckUnless.
>
> Similarly to CheckIf, CheckUnless is a deoptimization without a specific
> frame state. A frame state is assigned during effect-control linearization
> (and CheckUnless is turned into DeoptimizeUnless).
>
> At the moment, the new operator is only used at one place in native context
> specialization, but we should use it everywhere. The advantage of
> CHeckUnless is that it avoids non-truncating uses of values by frame
> states. This particular change is aimed at Octane's crypto, where this
> enables to turn one NumberMultiply into Int32Mul, and thus improve
> the score by more than 10% (it also needs minus zero truncation and
> typing to be improved, but those CLs are already in flight).
>
> BUG=v8:4470
> R=bmeurer@chromium.org
>
> Committed: https://crrev.com/85fde59d538e0dcaf461108086c2f7cf904f567a
> Cr-Commit-Position: refs/heads/master@{#37085}

TBR=bmeurer@chromium.org,jarin@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/2078333002
Cr-Commit-Position: refs/heads/master@{#37090}

Import base::ieee754::tan() from fdlibm and introduce Float64Tan TurboFan
operator based on that, similar to what we do for Float64Cos and Float64Sin.
Rewrite Math.tan() as TurboFan builtin and use those operators to also
inline Math.tan() into optimized TurboFan functions.

Drive-by-fix: Kill the %_ConstructDouble intrinsics, and provide only
the %ConstructDouble runtime entry for writing tests.

BUG=v8:5086,v8:5126
R=yangguo@chromium.org

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

Similarly to CheckIf, CheckUnless is a deoptimization without a specific
frame state. A frame state is assigned during effect-control linearization
(and CheckUnless is turned into DeoptimizeUnless).

At the moment, the new operator is only used at one place in native context
specialization, but we should use it everywhere. The advantage of
CHeckUnless is that it avoids non-truncating uses of values by frame
states. This particular change is aimed at Octane's crypto, where this
enables to turn one NumberMultiply into Int32Mul, and thus improve
the score by more than 10% (it also needs minus zero truncation and
typing to be improved, but those CLs are already in flight).

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

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

This introduces handling number feedback for multiplication, division
and modulus. At the moment, the only effect is using deoptimizing
number conversion instead of ToNumber call.

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

Import base::ieee754::cos() and base::ieee754::sin() from fdlibm and
introduce Float64Cos and Float64Sin TurboFan operator based on that,
similar to what we do for Float64Log. Rewrite Math.cos() and Math.sin()
as TurboFan builtins and use those operators to also inline Math.cos()
and Math.sin() into optimized TurboFan functions.

CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
R=mvstanton@chromium.org
BUG=v8:5086,v8:5118

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

BUG=v8:5103

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

Import base::ieee754::exp() from FreeBSD msun and introduce a Float64Exp
TurboFan operator based on that, similar to what we do for Float64Log.
Rewrite Math.exp() as TurboFan builtin and use that operator to also
inline Math.exp() into optimized TurboFan functions.

CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
BUG=v8:3266,v8:3468,v8:3493,v8:5086,v8:5108,chromium:620786
R=mvstanton@chromium.org

Committed: https://crrev.com/93e26314afc9da9b5b8bd998688262444ed73260
Review-Url: https://codereview.chromium.org/2077533002
Cr-Original-Commit-Position: refs/heads/master@{#37037}
Cr-Commit-Position: refs/heads/master@{#37047}

Revert of [builtins] Introduce proper Float64Exp operator. (patchset #5 id:80001 of https://codereview.chromium.org/2077533002/ )

Reason for revert:
[Sheriff] Leads to some different rounding as it seems in some audio layout tests. Please rebase upstream first if intended:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/7508

Original issue's description:
> [builtins] Introduce proper Float64Exp operator.
>
> Import base::ieee754::exp() from FreeBSD msun and introduce a Float64Exp
> TurboFan operator based on that, similar to what we do for Float64Log.
> Rewrite Math.exp() as TurboFan builtin and use that operator to also
> inline Math.exp() into optimized TurboFan functions.
>
> BUG=v8:3266,v8:3468,v8:3493,v8:5086,v8:5108
> R=mvstanton@chromium.org
>
> Committed: https://crrev.com/93e26314afc9da9b5b8bd998688262444ed73260
> Cr-Commit-Position: refs/heads/master@{#37037}

TBR=mvstanton@chromium.org,ahaas@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:3266,v8:3468,v8:3493,v8:5086,v8:5108

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

Import base::ieee754::exp() from FreeBSD msun and introduce a Float64Exp
TurboFan operator based on that, similar to what we do for Float64Log.
Rewrite Math.exp() as TurboFan builtin and use that operator to also
inline Math.exp() into optimized TurboFan functions.

BUG=v8:3266,v8:3468,v8:3493,v8:5086,v8:5108
R=mvstanton@chromium.org

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

BUG=v8:5095

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

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

This CheckBounds simplified operator is similar to the HBoundsCheck in
Crankshaft, and is hooked up to the new type feedback support in the
SimplifiedLowering. We use it to check the index bounds for keyed
property accesses.

Note to perf sheriffs: This will tank quite a few benchmarks, as the
operator makes some redundant branch elimination ineffective for
certain patterns of keyed accesses. This does require more serious
redundancy elimination, which we will do in a separate CL. So ignore
any regressions from this CL, we know there will be a few.

R=jarin@chromium.org
BUG=v8:4470,v8:5100

Committed: https://crrev.com/85e5567dae66a918500ae94c5568221137a0f5d4
Review-Url: https://codereview.chromium.org/2035893004
Cr-Original-Commit-Position: refs/heads/master@{#36947}
Cr-Commit-Position: refs/heads/master@{#37003}

These simplified operators are used to perform the hole checks when
loading elements from a holey array. Depending on the CheckHoleMode,
they either return the hole as undefined or some NaN, or deoptimize
if the value is the hole or the hole NaN.

R=jarin@chromium.org

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

Now that we have the PlainPrimitiveToNumber operator(s), we can unify
all the places where we expect a number, but can also safely handle any
plain-primitive (via ToNumber truncation).

Drive-by-fix: Also handle Math.min consistently with Math.max.

R=jarin@chromium.org

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

Revert of [turbofan] Introduce a dedicated CheckBounds operator. (patchset #5 id:80001 of https://codereview.chromium.org/2035893004/ )

Reason for revert:
Speculative revert since V8 roll is blocked.

Buildbot: https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_chromeos_rel_ng/builds/228171

Example log: https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_chromeos_rel_ng/builds/228171/steps/browser_tests%20%28with%20patch%29%20on%20Ubuntu-12.04/logs/CreateNewFolder_FileManagerBrowserTest.Test_0

Failing assert:
#
# Fatal error in ../../v8/src/compiler/node.cc, line 63
# Node::New() Error: #202:DeoptimizeUnless[1] is nullptr
#

(I take it that's a rather generic assert in TF, hence the revert is somewhat sepculative.)

Original issue's description:
> [turbofan] Introduce a dedicated CheckBounds operator.
>
> This CheckBounds simplified operator is similar to the HBoundsCheck in
> Crankshaft, and is hooked up to the new type feedback support in the
> SimplifiedLowering. We use it to check the index bounds for keyed
> property accesses.
>
> Note to perf sheriffs: This will tank quite a few benchmarks, as the
> operator makes some redundant branch elimination ineffective for
> certain patterns of keyed accesses. This does require more serious
> redundancy elimination, which we will do in a separate CL. So ignore
> any regressions from this CL, we know there will be a few.
>
> R=jarin@chromium.org
> BUG=v8:4470,v8:5100
>
> Committed: https://crrev.com/85e5567dae66a918500ae94c5568221137a0f5d4
> Cr-Commit-Position: refs/heads/master@{#36947}

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

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

This is part of the fixes required to make type feedback viable for
TurboFan on Octane.

R=jarin@chromium.org

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

This introduces SilenceNaN operator, which makes sure that we only
store quiet NaNs into holey arrays. We omit the NaN silencing code
at instruction selection time if the input is an operation that
cannot possibly produce signalling NaNs.

BUG=

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

This CheckBounds simplified operator is similar to the HBoundsCheck in
Crankshaft, and is hooked up to the new type feedback support in the
SimplifiedLowering. We use it to check the index bounds for keyed
property accesses.

Note to perf sheriffs: This will tank quite a few benchmarks, as the
operator makes some redundant branch elimination ineffective for
certain patterns of keyed accesses. This does require more serious
redundancy elimination, which we will do in a separate CL. So ignore
any regressions from this CL, we know there will be a few.

R=jarin@chromium.org
BUG=v8:4470,v8:5100

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

Import base::ieee754::atan() and base::ieee754::atan2() from fdlibm and
introduce Float64Atan and Float64Atan2 TurboFan operators based on those,
similar to what we already did for Float64Log and Float64Log1p. Rewrite
Math.atan() and Math.atan2() as TurboFan builtin and use the operators
to also inline Math.atan() and Math.atan2() into optimized TurboFan functions.

R=yangguo@chromium.org
BUG=v8:5086,v8:5095

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

Import base::ieee754::log1p() from fdlibm and introduce a Float64Log1p
TurboFan operator based on that, similar to what we do for Float64Log.
Rewrite Math.log1p() as TurboFan builtin and use that operator to also
inline Math.log1p() into optimized TurboFan functions.

Also unify the handling of the special IEEE 754 functions somewhat in
the TurboFan backends. At some point we can hopefully express this
completely in the InstructionSelector (once we have an idea what to do
with the ST(0) return issue on IA-32/X87).

Drive-by-fix: Add some more test coverage for the log function.

R=yangguo@chromium.org
BUG=v8:5086,v8:5092

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

This should solve the problem with missing checkpoints after JSToNumber
(PlainPrimitiveToNumber is marked no-write, so the frame-state
propagation should see through it.)

Unfortunately, this also duplicates the word32- and float64-truncation
magic that we have for JSToNumber in "simplified lowering".

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

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

Type feedback introduced DeoptimizeIf node in representation inference
(for Int32AddWithOverflow); we found the frame state for the deopt by
walking the effect chain. Unfortunately, the effect chain can hit
effect merges introduced by simplified lowering (e.g., in LoadBuffer)
and thus fail the assertion (we refuse to go through effect phis).

This CL postpones assignment of the frame state to the effect-control
lninearizer, so that we can correctly propagate the frame state to
the deopt point. The DeoptimizeIf node with unassigned frame state is
called CheckIf.

BUG=

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

Introduce a dedicated Float64Log machine operator, that is either
implemented by a direct C call or by platform specific code, i.e.
using the FPU on x64 and ia32.

This operator is used to implement Math.log as a proper TurboFan
builtin on top of the CodeStubAssembler.

Also introduce a NumberLog simplified operator on top of Float64Log
and use that for the fast inline path of Math.log inside TurboFan
optimized code.

BUG=v8:5065

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

This introduces optimized number operations based on type feedback.

Summary of changes:

1. Typed lowering produces SpeculativeNumberAdd/Subtract for JSAdd/Subtract if
   there is suitable feedback. The speculative nodes are connected to both the
   effect chain and the control chain and they retain the eager frame state.

2. Simplified lowering now executes in three phases:
  a. Propagation phase computes truncations by traversing the graph from uses to
     definitions until checkpoint is reached. It also records type-check decisions
     for later typing phase, and computes representation.
  b. The typing phase computes more precise types base on the speculative types (and recomputes
     representation for affected nodes).
  c. The lowering phase performs lowering and inserts representation changes and/or checks.

3. Effect-control linearization lowers the checks to machine graphs.

Notes:

- SimplifiedLowering will be refactored to have handling of each operation one place and
  with clearer input/output protocol for each sub-phase. I would prefer to do this once
  we have more operations implemented, and the pattern is clearer.

- The check operations (Checked<A>To<B>) should have some flags that would affect
  the kind of truncations that they can handle. E.g., if we know that a node produces
  a number, we can omit the oddball check in the CheckedTaggedToFloat64 lowering.

- In future, we want the typer to reuse the logic from OperationTyper.

BUG=v8:4583
LOG=n

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

We use StringFromCharCode to optimize calls to String.fromCharCode with
a single Number argument for now. We will use it to also implement the
charAt method on the String prototype.

R=jarin@chromium.org

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