Deletes AstGraphBuilder and associated classes now that it is
unreachable. The following classes are also removed:
- ControlBuilders
- JSFrameSpecialization
- AstLoopAssignmentAnalysis
Also removes flags from compilation-info which are no longer used, and removes
the no-deoptimization paths from TypedOptimization, JsTypedLowering,
JSIntrinsicLowering and JSBuiltinLowering.
BUG=v8:6409
Change-Id: I63986e8e3497bf63c4a27ea8ae827b8a633d4a26
Reviewed-on: https://chromium-review.googlesource.com/583652
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47284}
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}
Use HeapConstant for string_iterator_map rather than loading it
manually. This avoids unnecessary map checks.
BUG= v8:3822,v8:5267
Review-Url: https://codereview.chromium.org/2479563003
Cr-Commit-Position: refs/heads/master@{#40741}
Migrate the isNaN, isFinite, Number.isFinite, Number.isInteger,
Number.isSafeInteger and Number.isNaN predicates to TurboFan
builtins and make them optimizable (for certain input types) in
JavaScript callees being optimized by TurboFan. That means both
the baseline and the optimized version is now always at maximum,
consistent performance. Especially TurboFan suffered from poor
baseline (and optimized) performance because it cannot play the
same weird tricks that Crankshaft plays for %_IsSmi.
This also adds a bunch of new tests to properly cover the use
of the Harmony predicates in optimized code.
R=franzih@chromium.org
BUG=v8:5049,v8:5267
Review-Url: https://codereview.chromium.org/2313073002
Cr-Commit-Position: refs/heads/master@{#39242}
This adds a very first version of inlined Array.prototype.pop into
TurboFan optimized code. We currently limit the inlining to fast
object or smi elements, until the unclear situation around hole NaNs
is resolved and we have a clear semantics inside the compiler.
It's also probably overly defensive in when it's safe to inline
the call to Array.prototype.pop, but we can always extend that
later once we have sufficient trust in the implementation and see
an actual need to extend it.
BUG=v8:2229,v8:3952,v8:5267
R=epertoso@chromium.org
Review-Url: https://codereview.chromium.org/2239703002
Cr-Commit-Position: refs/heads/master@{#38578}
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}
The Number.parseInt (and therefore the parseInt function on the global
object) are often used instead of Math.floor or just plain int32
truncation, and we can easily recognize those cases and provide a fast
path in TurboFan.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2125583002
Cr-Commit-Position: refs/heads/master@{#37518}
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.orgR=franzih@chromium.org
Review-Url: https://codereview.chromium.org/2116753002
Cr-Commit-Position: refs/heads/master@{#37476}
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}
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}
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}
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 removes the frame state input representing the before-state from
nodes having the {JSCallFunction} or {JSCallConstruct} operator. 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/2025573003
Cr-Commit-Position: refs/heads/master@{#36669}
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}
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 removes the language mode parameter from all JSCall operators. The
information is no longer used anywhere and is not threaded through the
interpreter bytecode. We should only thread it through the bytecode if
it has a semantic impact on the compilation.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1709493002
Cr-Commit-Position: refs/heads/master@{#34073}
MachineType is now a class with two enum fields:
- MachineRepresentation
- MachineSemantic
Both enums are usable on their own, and this change switches some places from using MachineType to use just MachineRepresentation. Most notably:
- register allocator now uses just the representation.
- Phi and Select nodes only refer to representations.
Review URL: https://codereview.chromium.org/1513543003
Cr-Commit-Position: refs/heads/master@{#32738}
Use the Call builtin instead, which does the right thing(TM)
always, especially since the CallFunctionStub is going away.
R=jarin@chromium.org
BUG=v8:4413
LOG=n
Review URL: https://codereview.chromium.org/1410853007
Cr-Commit-Position: refs/heads/master@{#31794}
In order to properly (lazy) bailout when converting the receiver for
sloppy mode functions (using the newly added JSConvertReceiver
operator), we need to have a bailout location right before every call
(also right before every %_Call and %_CallFunction), otherwise if the
JSConvertReceiver just reuses the lazy bailout frame state from the
JSCallFunction node, it will skip the whole function in case of lazy
bailout.
Note it should be impossible to trigger this currently because we do not
yet support AllocationSite code dependencies in TurboFan, which can
trigger this kind of lazy bailout; therefore it's not possible to write
a regression test (yet).
R=yangguo@chromium.org
BUG=v8:4493
LOG=n
Review URL: https://codereview.chromium.org/1425883004
Cr-Commit-Position: refs/heads/master@{#31668}
This removes all locally constructed SimplifiedOperatorBuilder instances
and uses the one passed along the JSGraph. It ensures that the correct
zone is used to allocate operators, no matter where the reducer is used.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1410003002
Cr-Commit-Position: refs/heads/master@{#31355}
This fixes the lifetime of nodes created by JSGlobalSpecialization that
contain a simplified operator. In the case where this reducer runs as
part of the inliner, the SimplifiedOperatorBuilder was instantiated with
the wrong zone. This led to use-after-free of simplified operators.
To avoid such situations in the future, we decided to move this operator
builder into the JSGraph and make the situation uniform with all other
operator builders.
R=bmeurer@chromium.org
BUG=chromium:543528
LOG=n
Review URL: https://codereview.chromium.org/1409993002
Cr-Commit-Position: refs/heads/master@{#31334}
This CL us a pure refactoring that makes an empty compilation unit
including just "isolate.h" or "contexts.h" but not "objects-inl.h"
compile without warnings or errors. This is needed to further reduce
the header dependency tangle.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1322883002
Cr-Commit-Position: refs/heads/master@{#30500}
The usage of Unique<T> throughout the TurboFan IR does not have any
advantage. There is no single point in time when they are initialized
and most use-sites looked through to the underlying Handle<T> anyways.
Also there already was a mixture of Handle<T> versus Unique<T> in the
graph and this unifies the situation to use Handle<T> everywhere.
R=bmeurer@chromium.org,titzer@chromium.org
Review URL: https://codereview.chromium.org/1314473007
Cr-Commit-Position: refs/heads/master@{#30458}
This in turn allows usage of AdvancedReducer::ReplaceWithValue which
has access to the underlying graph reducer. It will allow us to deal
with exception continuations correctly.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1158273011
Cr-Commit-Position: refs/heads/master@{#28813}
Reduces the amount of custom support code for Math functions in TurboFan
and allows for more general inlining (i.e. independent of parameter
types).
BUG=v8:3952
LOG=n
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1004083002
Cr-Commit-Position: refs/heads/master@{#27172}
Provide an intrinsic %MathFloor / %_MathFloor that is used to optimize
both Math.ceil and Math.floor, and use the JS inlining mechanism to
inline Math.ceil into TurboFan code. Although we need to touch code
outside of TurboFan to make this work, this does not affect the way we
handle Math.ceil and/or Math.floor in CrankShaft, because for CrankShaft
the old-style builtin function id based inlining still kicks in first.
Once this solution is stabilized, we can use it for Math.floor as well.
And once that is settled, we can establish it as the unified way to
inline builtins, and get rid of the specialized builtin function id
based inlining at some point.
Note that "builtin" applies to basically every piece of internal
JavaScript/intrinsics based code, so this also applies to the yet to be
defined JavaScript based code stubs and handlers.
BUG=v8:3953
LOG=n
R=yangguo@chromium.org,svenpanne@chromium.org
Review URL: https://codereview.chromium.org/990963003
Cr-Commit-Position: refs/heads/master@{#27086}
Along the way:
- Thread isolate parameter explicitly through code that used to
rely on getting it from the zone.
- Canonicalize the parameter position of isolate and zone for
affected code
- Change Hydrogen New<> instruction templates to automatically
pass isolate
R=mstarzinger@chromium.org
LOG=N
Review URL: https://codereview.chromium.org/868883002
Cr-Commit-Position: refs/heads/master@{#26252}
Reason for revert:
Breaks test-types/Maybe, i.e.
out/Release/cctest --random-seed=-707413401 test-types/Maybe
started failing afterwards
Original issue's description:
> Steps towards unification of number bitset and range types.
>
> - New invariant on union types: if the union has a range then the number
> bits in the bitset must be cleared.
>
> - Various tweaks in intersection and union to satisfy the invariant.
>
> - Exposed and used representation bits in range types (and the Limits
> helper class).
>
> - Implemented Glb for ranges so that the Is predicate handles
> ranges correctly.
>
> - Change typer weakening so that it does not rely on GetRange.
> However, the code still seems to be a bit fragile.
>
> - Removed the Smi types from the type system core, instead introduced
> Signed31, Unsigned30 and created constructors for Small(Un)Signed
> that point to the right type for the architecture.
>
> - Punched a hole in the config to be able to get to the isolate so
> that it is possible to allocate heap numbers for newly created
> ranges.
>
> Patch by jarin@chromium.prg, original review here:
> https://codereview.chromium.org/795713003/
>
> TBR=jarin@chromium.org
> BUG=
>
> Committed: https://crrev.com/2764fd8d1a266a9136c987c2483492113b0c8d80
> Cr-Commit-Position: refs/heads/master@{#26197}
TBR=jkummerow@chromium.org,rossberg@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/868583002
Cr-Commit-Position: refs/heads/master@{#26207}
- New invariant on union types: if the union has a range then the number
bits in the bitset must be cleared.
- Various tweaks in intersection and union to satisfy the invariant.
- Exposed and used representation bits in range types (and the Limits
helper class).
- Implemented Glb for ranges so that the Is predicate handles
ranges correctly.
- Change typer weakening so that it does not rely on GetRange.
However, the code still seems to be a bit fragile.
- Removed the Smi types from the type system core, instead introduced
Signed31, Unsigned30 and created constructors for Small(Un)Signed
that point to the right type for the architecture.
- Punched a hole in the config to be able to get to the isolate so
that it is possible to allocate heap numbers for newly created
ranges.
Patch by jarin@chromium.prg, original review here:
https://codereview.chromium.org/795713003/TBR=jarin@chromium.org
BUG=
Review URL: https://codereview.chromium.org/837723006
Cr-Commit-Position: refs/heads/master@{#26197}
