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}

This will be used to pass parameters of wasm functions to the wasm
interpreter. All of them need to be packed into one buffer, which is
then passed to the interpreter.

R=ahaas@chromium.org, titzer@chromium.org
BUG=v8:5822

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

All issues in interpreter bytecode handlers are fixed.

BUG=

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

Also lower JSToBoolean(x) where x is either some detectable receiver or
null, or any kind of receiver, null or undefined. Also fix a couple of
minor issues with the JSToBoolean lowering and tests.

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

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

This adds a new ExternalPointer type, which is an Internal type that is
used for ExternalReferences and other pointer values, like the pointers
into the asm.js heap. It also adds a PointerConstant operator, which we
use to represents these raw constants (we can probably remove that
particular operator again once WebAssembly ships with the validator).

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

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

They are nops, but will be used when verifying the machine graph.

BUG=

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

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}

Previously we always lowered JSToBoolean(x:Number) to the subgraph
NumberLessThan(0.0, NumberAbs(x)), which deals with both 0, -0 and
NaNs appropriately. However this doesn't always generate the best,
especially when we can later derive from feedback that x is always
an Integral32 value, where the ideal code would be just a single
comparison to 0 w/o the absolute value computation.

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

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

If the type of a tracked field or element value is less precise than the
advertised type of the field or element load, then we replace the load
operation with a TypeGuard that guards the advertised type.

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

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

Up until now "-0.0 - x" was lowered in the instruction selector. I moved
the lowering now to the MachineOperatorReducer.

I did not remove the lowering from the instruction selector yet, I would
prefer to do that in a separate CL.

R=bmeurer@chromium.org

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

Introduce a dedicated NumberOperationHint enum that represents the
feedback we can use for speculative number operations.

BUG=v8:4930

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

BUG=

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

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}

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}

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}

Add simple strength reduction for Int32MulWithOverflow to the
MachineOperatorReducer.

R=mvstanton@chromium.org

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

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}

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}

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}

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}

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}

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}

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}

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}

These speculative binary operators are simplified operators and should
not need a frame state themselves. These eager bailout points can by now
be found via checkpoints in the graph, whereas frame states attached to
nodes directly should always represent lazy bailout points.

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

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

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}

The type guard should never be used after the effect/control
linearization pass, so making it a simplified operator better
expresses the intended use. Also this way none of the common
operators actually has any dependency on the type system.

Drive-by-fix: Properly print the type parameter to a TypeGuard operator.

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

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

We eagerly inserted Int32Mul for Math.imul during builtin lowering and
messed up with the types, which confused the representation selection.
This adds a proper NumberImul operator, and fixes the builtin reducer to
do the right thing according to the spec.

R=mstarzinger@chromium.org
BUG=v8:5006
LOG=n

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

This operator was initially designed to handle arbitrary effect merging
for effect relaxation, but we don't do that (at least currently). So no
need to keep the dead operator around.

R=jarin@chromium.org

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