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}
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}
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}
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}
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 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}
This allows us to get rid of the "push TruncateFloat64ToInt32 into Phi"
trick that was used in the MachineOperatorReducer to combine the
ChangeTaggedToFloat64 and TruncateFloat64ToInt32 operations. Instead of
doing that later, we can just introduce the proper operator during the
representation selection directly.
Also separate the TruncateFloat64ToInt32 machine operator, which had two
different meanings depending on a flag (either JavaScript truncation or
C++ style round to zero). Now there's a TruncateFloat64ToWord32 which
represents the JavaScript truncation (implemented via TruncateDoubleToI
macro + code stub) and the RoundFloat64ToInt32, which implements the C++
round towards zero operation (in the same style as the other WebAssembly
driven Round* machine operators).
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1919513002
Cr-Commit-Position: refs/heads/master@{#35743}
Removes the register file machine register from the interpreter and
replaces it will loads from the parent frame pointer. As part of this
change the raw operand values for register values changes to enable the
interpreter to keep using the operand value as the offset from the
parent frame pointer.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1894063002
Cr-Commit-Position: refs/heads/master@{#35618}
Int64Mul is lowered to a new turbofan operator, Int32MulPair. The new
operator takes 4 inputs an generates 2 outputs. The inputs are the low
word of the left input, high word of the left input, the low word of the
right input, and high word of the right input. The ouputs are the low
and high word of the result of the multiplication.
R=titzer@chromium.org, v8-arm-ports@googlegroups.com
Review URL: https://codereview.chromium.org/1807273002
Cr-Commit-Position: refs/heads/master@{#35131}
The CL also add guard nodes to places where we assume that certain
values are numbers.
Review URL: https://codereview.chromium.org/1821133002
Cr-Commit-Position: refs/heads/master@{#34977}
Int64Sub is lowered to a new turbofan operator, Int32SubPair. The new
operator takes 4 inputs an generates 2 outputs. The inputs are the low
word of the left input, high word of the left input, the low word of the
right input, and high word of the right input. The ouputs are the low
and high word of the result of the subtraction.
The implementation is very similar to the implementation of Int64Add.
@v8-arm-ports: please take a careful look at the implementation of sbc
in the simulator.
R=titzer@chromium.org, v8-arm-ports@googlegroups.com
Review URL: https://codereview.chromium.org/1778893005
Cr-Commit-Position: refs/heads/master@{#34808}
Word64Popcnt is lowered to Word32Popcnt(low-word) + Word32Popcnt(high_word).
Since the optional Word64Popcnt operator does not exist on 32 bit platforms,
I introduced a new operator "Word64PopcntPlaceholder" which is generated
in the WasmCompiler and then lowered in the Int64Lowering.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1803453003
Cr-Commit-Position: refs/heads/master@{#34777}
Int64Add is lowered to a new turbofan operator, Int32AddPair. The new
operator takes 4 inputs an generates 2 outputs. The inputs are the low
word of the left input, high word of the left input, the low word of the
right input, and high word of the right input. The ouputs are the low
and high word of the result of the addition.
R=titzer@chromium.org, v8-arm-ports@googlegroups.com
Review URL: https://codereview.chromium.org/1778493004
Cr-Commit-Position: refs/heads/master@{#34747}
I64Shl is lowered to a new turbofan operator, WasmWord64Shl. The new
operator takes 3 inputs, the low-word input, the high-word input, and
the shift, and produces 2 output, the low-word output and the high-word
output.
At the moment I implemented the lowering only for ia32, but I think the
CL is already big enough. I will add the other platforms in separate
CLs.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1756863002
Cr-Commit-Position: refs/heads/master@{#34546}
Avoid the hacking in JSIntrinsicLowering and provide a proper simplified
operator ObjectIsReceiver instead that is used to implement %_IsJSReceiver
which is used by our JavaScript builtins and the JSInliner.
R=jarin@chromium.org
BUG=v8:4544
LOG=n
Review URL: https://codereview.chromium.org/1657863004
Cr-Commit-Position: refs/heads/master@{#33675}
Removes the dummy control and effect edges from the RMA Call nodes. This
requires a change to the node matchers to allow them to cope with nodes
which don't have control or effect matchers.
Review URL: https://codereview.chromium.org/1518673002
Cr-Commit-Position: refs/heads/master@{#32752}
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}
an optomization to remove redundant cast operations.
1. Adds an optimization to remove redundant ToBoolean and ToName operations.
2. Adds implementation and tests for cast operatorts to bytecode graph builder.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1468003002
Cr-Commit-Position: refs/heads/master@{#32408}
Removing bytecode graph builder tests as they are high maintenance and
have limited use, ie they track changes in the implementation rather
than behaviour.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1477783003
Cr-Commit-Position: refs/heads/master@{#32333}
Adds code and tests to support CreateClosure bytecode when building
graphs.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1458603012
Cr-Commit-Position: refs/heads/master@{#32224}
Adds support for the New, CallRuntime and CallJSRuntime bytecodes in
BytecodeGraphBuilder. Also adds BuildLoadObjectField,
BuildLoadGlobalObject and BuildLoadNativeContextField helpers.
Landed on behalf of rmcilroy.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1456483002
Cr-Commit-Position: refs/heads/master@{#32136}
This fixes undefined behavior with the OpParameter helper in some of our
node matchers. There was a constness mismatch of the template parameter.
R=oth@chromium.org,mythria@chromium.org
Review URL: https://codereview.chromium.org/1453973004
Cr-Commit-Position: refs/heads/master@{#32087}
Adds support for the LdaGlobal and StaGlobal bytecodes to the
BytecodeGraphBuilder. Also fixes a bug in the context node's parameter
index and start node inputs.
Landed on behalf of rmcilroy.
TBR=bmeuer@chromium.org,mythria@chromium.org
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1449373002
Cr-Commit-Position: refs/heads/master@{#32049}
Adds support for visiting the Call bytecode to the bytecode graph builder.
This change also adds the call type feedback slot to the Call bytecode.
This is not currently used by the interpreter, but is used by the
graph builder.
Also adds a CallWide varient of the Call bytecode, and adds the kCount16
operand type.
Landed on behalf of rmcilroy.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1456453002
Cr-Commit-Position: refs/heads/master@{#32033}
Adds implementation and tests for following operators in bytecode graph builder:
-VisitLoadICSloppy
-VisitLoadICStrict
-VisitLoadICSloppyWide
-VisitLoadICStrictWide
The current implementation introduces empty frame states for frame state inputs expected by these operations.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1419373007
Cr-Commit-Position: refs/heads/master@{#32026}
This CL re-purposes ValueEffect and Finish as delimiters for regions
that are scheduled atomically (renamed to BeginRegion, FinishRegion).
The BeginRegion node takes and produces an effect. For the uses that do
not care about the placement in the effect chain, it is ok to feed
graph->start() as an effect input.
The FinishRegion takes a value and an effect and produces a value and
an effect. It is important that any value or effect produced inside the
region is not used outside the region. The FinishRegion node is the only
way to smuggle an effect and a value out.
At the moment, this does not support control flow inside the region. Control flow would be hard.
During scheduling we do some sanity check, but the checks are not exhaustive. Here is what we check:
- the effect chain between begin and finish is linear (no splitting,
single effect input and output).
- any value produced is consumed by the FinishRegion node.
- no control flow outputs.
Review URL: https://codereview.chromium.org/1399423002
Cr-Commit-Position: refs/heads/master@{#31265}
Adds support for short operands, starting with kIdx16. Introduces
BytecodeTraits to enable compile time determination of various traits for a
bytecode, such as size, operands, etc. Reworks BytecodeIterator,
BytecodeArrayBuilder and Bytecodes::Decode to support 16 bit operands. Adds
support to Interpreter to load 16 bit operands.
Also fixes a bug with ToBoolean where it wouldn't get emitted at the start
of a block, and added a test.
BytecodeTraits template magic inspired by oth@chromium.org.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1370893002
Cr-Commit-Position: refs/heads/master@{#31058}
Similar to DELETE, the IN builtin is just a thin wrapper for %HasElement
and %HasProperty anyway, and cannot be optimized, plus it had a weird
special fast case (which also involved at least one LOAD_IC plus some
intrinsic magic).
R=yangguo@chromium.org,jarin@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_win_nosnap_shared_rel
Committed: https://crrev.com/72d60a1e80e81e2e68ca402665e2acbc46c5e471
Cr-Commit-Position: refs/heads/master@{#30154}
Review URL: https://codereview.chromium.org/1295433002
Cr-Commit-Position: refs/heads/master@{#30582}
Now that it is no longer needed, this also removes the invalid inclusion
of "object-inl.h" within the "unique.h" header file.
Note that this change still leaves 2 violations of that rule in the
code, checked with the "tools/check-inline-includes.sh" tool.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1321223002
Cr-Commit-Position: refs/heads/master@{#30503}
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}
Adds implementations and tests for the following bytecodes:
- Add
- Sub
- Mul
- Div
- Mod
Also adds the Mod bytecode and adds support to BytecodeGenerator and
BytecodeArrayBuilder to enable it's use.
The current bytecodes always call through to the JS builtins. This also adds
LoadObjectField and CallJSBuiltin operators to the InterpreterAssembler.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1300813005
Cr-Commit-Position: refs/heads/master@{#30352}
Passes the current context to bytecode interpreter handlers. This is held in the
context register on all architectures except for ia32 where there are too few
registers and it is instead spilled to the stack.
Also changes Load/StoreRegister to use kMachAnyTagged representation since they
should only ever hold tagged values.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1294133004
Cr-Commit-Position: refs/heads/master@{#30325}
Makes the following modifications to the interpreter builtins and
InterpreterAssembler:
- Adds an accumulator register and initializes it to undefined()
- Adds a register file pointer register and use it instead of FramePointer to
access registers
- Modifies builtin to support functions with 0 regiters in the register file
- Modifies builtin to Call rather than TailCall to first bytecode handler.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1289863003
Cr-Commit-Position: refs/heads/master@{#30219}
Adds interpreter entry and exit trampoline builtins. Also implements the
Return bytecode handler and fixes a few bugs in InterpreterAssembler
highlighted by running on other architectures.
MIPS and MIPS64 port contributed by Paul Lind (paul.lind@imgtec.com)
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1245133002
Cr-Commit-Position: refs/heads/master@{#29929}
Changes the interpreter to use a BytecodeArray pointer and an offset to avoid
having an inner pointer to a BytecodeArray object in registers during dispatch.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1254293006
Cr-Commit-Position: refs/heads/master@{#29910}
Adds basic support for generation of interpreter bytecode handler code
snippets. The InterpreterAssembler class exposes a set of low level,
interpreter specific operations which can be used to build a Turbofan
graph. The Interpreter class generates a bytecode handler snippet for
each bytecode by assembling operations using an InterpreterAssembler.
Currently only two simple bytecodes are supported: LoadLiteral0 and Return.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1239793002
Cr-Commit-Position: refs/heads/master@{#29814}
Reduce Float64 comparison to Float32 when both inputs are conversions from
Float32.
Review URL: https://codereview.chromium.org/1235663002
Cr-Commit-Position: refs/heads/master@{#29586}
Currently we lower shifts directly to machine operators, and add an
appropriate Word32And to implement the & 0x1F operation on the right
hand side required by the specification. However for Word32And we assume
Int32 in simplified lowering, which is basically changes the right hand
side bit interpretation for the shifts from Uint32 to Int32, which is
obviously wrong. So now we represent that explicitly by proper
simplified operators for the shifts, which are lowered to machine in
simplified lowering.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1213803008
Cr-Commit-Position: refs/heads/master@{#29465}
This will enable tail call optimization even across inlining. Plus it
might enable some other interesting optimizations as well. In order to
avoid blowing up the generated code, we can still canonicalize the
epilogue in the CodeGenerator, similar to what fullcodegen does.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1215623002
Cr-Commit-Position: refs/heads/master@{#29311}
The three different concerns that the ControlReducer used to deal with
are now properly separated into
a.) DeadCodeElimination, which is a regular AdvancedReducer, that
propagates Dead via control edges,
b.) CommonOperatorReducer, which does strength reduction on common
operators (i.e. Branch, Phi, and friends), and
c.) GraphTrimming, which removes dead->live edges from the graph.
This will make it possible to run the DeadCodeElimination together with
other passes that actually introduce Dead nodes, i.e. typed lowering;
and it opens the door for general inlining without two stage fix point
iteration.
To make the DeadCodeElimination easier and more uniform, we basically
reverted the introduction of DeadValue and DeadEffect, and changed the
Dead operator to produce control, value and effect. Note however that
this is not a requirement, but merely a way to make dead propagation
easier and more uniform. We could always go back and decide to have
different Dead operators if some other change requires that.
Note that there are several additional opportunities for cleanup now,
i.e. OSR deconstruction could be a regular reducer now, and we don't
need to use TheHole as dead value marker in the GraphReducer. And we can
actually run the dead code elimination together with the other passes
instead of using separate passes over the graph. We will do this in
follow up CLs.
R=jarin@chromium.org, mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1193833002
Cr-Commit-Position: refs/heads/master@{#29146}
This adds handling of JSLoadDynamicContext nodes to JSTypedLowering to
perform extension checks and an inline fast path. The fast path is a
context slot load targeting a specific context.
R=bmeurer@chromium.org
BUG=v8:4131
LOG=N
Review URL: https://codereview.chromium.org/1155543003
Cr-Commit-Position: refs/heads/master@{#28823}
This adds handling of JSLoadDynamicGlobal nodes to JSTypedLowering to
perform extension checks and an inline fast path. The fast path is a
global variable load from the global object.
R=bmeurer@chromium.org
BUG=v8:4131
LOG=N
Review URL: https://codereview.chromium.org/1150723005
Cr-Commit-Position: refs/heads/master@{#28750}
If both inputs to JSStrictEqual/JSStrictNotEqual are unique values (i.e.
values with a canonical representation), we can lower the comparison to
ReferenceEqual instead of StringEqual or CompareIC.
Review URL: https://codereview.chromium.org/1154303002
Cr-Commit-Position: refs/heads/master@{#28646}
This simplifies the handling of the End node. Based on this CL we will
finally fix terminating every loop from the beginning (via Terminate
nodes) and fix inlining of Throw, Deoptimize and Terminate.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1157023002
Cr-Commit-Position: refs/heads/master@{#28620}
This revives the Terminate operator and removes the weird Always
operator. As a first step we let the ControlReducer connect non
terminating loops via Terminate. The next step will be to change the
graph builder to insert Terminate nodes into every loop.
Review URL: https://codereview.chromium.org/1123213002
Cr-Commit-Position: refs/heads/master@{#28259}
Tail calls are matched on the graph, with a dedicated tail call
optimization that is actually testable. The instruction selection can
still fall back to a regular if the platform constraints don't allow to
emit a tail call (i.e. the return locations of caller and callee differ
or the callee takes non-register parameters, which is a restriction that
will be removed in the future).
Also explicitly limit tail call optimization to stubs for now and drop
the global flag.
BUG=v8:4076
LOG=n
Review URL: https://codereview.chromium.org/1114163005
Cr-Commit-Position: refs/heads/master@{#28219}
This introduces a simplified allocation operator which can be used to
model inline allocations in TurboFan. It is currently used for context
allocations, but still disabled because change lowering introduces
floating allocations outside the effect chain that interfere.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1109773002
Cr-Commit-Position: refs/heads/master@{#28195}
Now all nodes that care about deoptimization always take frame state
inputs no matter whether deoptimization is enabled for a particular
function. In case that deoptimization is off, the AstGraphBuilder just
inserts the empty frame state. This greatly simplifies the logic in
various places and makes testing easier as well, and is probably the
first step towards enabling --turbo-deoptimization by default.
There seems to be no noticable performance impact on asm.js programs.
Also fix the graph replay in order to regenerate the scheduler unittests.
Review URL: https://codereview.chromium.org/1106613003
Cr-Commit-Position: refs/heads/master@{#28026}
These operators compute the absolute floating point value of some
arbitrary input, and are implemented without any branches (i.e. using
vabs on arm, and andps/andpd on x86).
R=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/1066393002
Cr-Commit-Position: refs/heads/master@{#27662}
This reduces the overhead of typed lowering, because we lower
JSToBoolean/JSUnaryNot directly if possible, instead of first lowering
to AnyToBoolean, and then letting the SimplifiedOperatorReducer do the
further lowering.
Also remove some obsolete tests from the cctest suite that have since
been removed by proper unittests. And improve unitttest coverage for the
typed lowering cases.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/999173003
Cr-Commit-Position: refs/heads/master@{#27295}
Basically recognize certain x < y ? x : y constructs and turn that into
Float64Min/Float64Max operations, if the target machine supports that.
On x86 we lower to (v)minsd/(v)maxsd.
R=dcarney@chromium.org
Review URL: https://codereview.chromium.org/998283002
Cr-Commit-Position: refs/heads/master@{#27160}
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}
This adds support for the double bits intrinsics to TurboFan, and is
a first step towards fast Math functions inlined into TurboFan code
or even compiled by themselves with TurboFan.
Review URL: https://codereview.chromium.org/974313002
Cr-Commit-Position: refs/heads/master@{#27006}
