Reason for revert:
Must revert for now due to chromium api natives issues.
Original issue's description:
> Type Feedback Vector lives in the closure
>
> (RELAND: the problem before was a missing write barrier for adding the code
> entry to the new closure. It's been addressed with a new macro instruction
> and test. The only change to this CL is the addition of two calls to
> __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
> Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
> And Benedikt reviewed it as well.
>
> TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org
>
> BUG=
>
> Committed: https://crrev.com/bb31db3ad6de16f86a61f6c7bbfd3274e3d957b5
> Cr-Commit-Position: refs/heads/master@{#33741}
TBR=bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1670813005
Cr-Commit-Position: refs/heads/master@{#33766}
(RELAND: the problem before was a missing write barrier for adding the code
entry to the new closure. It's been addressed with a new macro instruction
and test. The only change to this CL is the addition of two calls to
__ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.
We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.
This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.
The heap change is trivial so I TBR Hannes for it...
Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
And Benedikt reviewed it as well.
TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1668103002
Cr-Commit-Position: refs/heads/master@{#33741}
So far, we've been moving down gaps wholesale. This change moves
individual move operations instead. This improves some benchmarks,
and should overall reduce code size, because it improves the chance of
reducing the number of moves.
For example, there are improvements on x64 in Emscripten (Bullet, in
particular) , JetStream geomean, Embenchen (zlib).
In the process of making this change, I noticed we can separate the
tasks performed by the move optimizer, as follows:
- group gaps into 1
- push gaps down, jumping instructions (these 2 were together before)
- merge blocks (and then push gaps down)
- finalize
We can do without a finalization list. This avoids duplicating storage -
we already have the list of instructions; it also simplifies the logic, since,
with this change, we may process an instruction's gap twice.
Compile time doesn't regress much (see pathological cases), but we
may want to avoid the allocations of the few sets used in the new code.
I'll do that in a subsequent change.
BUG=
Review URL: https://codereview.chromium.org/1634093002
Cr-Commit-Position: refs/heads/master@{#33715}
Move all the code that deals with falling back to object creation via
stubs to JSGenericLowering, where we can already deal well with stub
calls. This includes JSCreateLiteralArray, JSCreateLiteralObject,
JSCreateClosure, JSCreateFunctionContext and JSCreateArray.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1653353002
Cr-Commit-Position: refs/heads/master@{#33682}
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}
There's no point in having %_IsFunction as inline intrinsic, as it
is only used in non performance critical code, which is already full
of runtime calls anyway, so %IsFunction will do the trick as well.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1658123002
Cr-Commit-Position: refs/heads/master@{#33660}
This CL removes the Config templatization from the types. It is not
necessary anymore, after the HeapTypes have been removed.
The CL also changes the type hierarchy - the specific type kinds are
not inner classes of the Type class and they do not inherit from Type.
This is partly because it seems impossible to make this work without
templates. Instead, a new TypeBase class is introduced and all the
structural (i.e., non-bitset) types inherit from it.
The bitset type still requires the bit-munging hack and some nasty
reinterpret-casts to pretend bitsets are of type Type*. Additionally,
there is now the same hack for TypeBase - all pointers to the sub-types
of TypeBase are reinterpret-casted to Type*. This is to keep the type
constructors in inline method definitions (although it is unclear how
much that actually buys us).
In future, we would like to move to a model where we encapsulate Type*
into a class (or possibly use Type where we used to use Type*). This
would loosen the coupling between bitset size and pointer size, and
eventually we would be able to have more bits.
TBR=bradnelson@chromium.org
Review URL: https://codereview.chromium.org/1655833002
Cr-Commit-Position: refs/heads/master@{#33656}
Reason for revert:
problems on Mac64
Original issue's description:
> [turbofan] Add the StackSlot operator to turbofan.
>
> The StackSlot operator allows to allocate a spill slot on the stack. We
> are going to use this operator to pass floats through pointers to c
> functions, which we need for floating point rounding in the case where
> the architecture does not provide rounding instructions.
>
> R=titzer@chromium.org, v8-arm-ports@googlegroups.com, v8-ppc-ports@googlegroups.com, v8-mips-ports@googlegroups.com
>
> Committed: https://crrev.com/7a693437787090d62d937b862e29521debcc5223
> Cr-Commit-Position: refs/heads/master@{#33600}
TBR=titzer@chromium.org,v8-arm-ports@googlegroups.com,v8-mips-ports@googlegroups.com,v8-ppc-ports@googlegroups.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1644283002
Cr-Commit-Position: refs/heads/master@{#33601}
Reason for revert:
Bug: failing to use write barrier when writing code entry into closure.
Original issue's description:
> Reland of Type Feedback Vector lives in the closure
>
> (Fixed a bug found by nosnap builds.)
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
>
> TBR=hpayer@chromium.org
> BUG=
>
> Committed: https://crrev.com/d984b3b0ce91e55800f5323b4bb32a06f8a5aab1
> Cr-Commit-Position: refs/heads/master@{#33548}
TBR=bmeurer@chromium.org,yangguo@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1643533003
Cr-Commit-Position: refs/heads/master@{#33556}
(Fixed a bug found by nosnap builds.)
We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.
We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.
This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.
The heap change is trivial so I TBR Hannes for it...
TBR=hpayer@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1642613002
Cr-Commit-Position: refs/heads/master@{#33548}
Introduces the concept of transfer direction to register operands. This
enables the register translator to emit exactly the moves that a
bytecode having it's register operands translated needs.
BUG=v8:4280,v8:4675
LOG=N
Review URL: https://codereview.chromium.org/1633153002
Cr-Commit-Position: refs/heads/master@{#33544}
Reason for revert:
FAilure on win32 bot, need to investigate webkit failures.
Original issue's description:
> Type Feedback Vector lives in the closure
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
>
> TBR=hpayer@chromium.org
>
> BUG=
>
> Committed: https://crrev.com/a5200f7ed4d11c6b882fa667da7a1864226544b4
> Cr-Commit-Position: refs/heads/master@{#33518}
TBR=bmeurer@chromium.org,akos.palfi@imgtec.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1632993003
Cr-Commit-Position: refs/heads/master@{#33520}
We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.
We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.
This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.
The heap change is trivial so I TBR Hannes for it...
TBR=hpayer@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1563213002
Cr-Commit-Position: refs/heads/master@{#33518}
* Add caching to handling of dangling loads
* Add two unittests for load elimination on escaped objects
BUG=v8:4586
LOG=n
Review URL: https://codereview.chromium.org/1619103004
Cr-Commit-Position: refs/heads/master@{#33498}
moves, we move those to the node, and remove them from the
predecessors ("merge" them to the common node).
If only some of the moves are common, we don't do anything. This is
what this change addresses.
The bug linked below should be addressed by this change. The only
difference in codegen before/after the change that introduced the bug
was un-merged moves.
BUG=chromium:549262
LOG=N
Review URL: https://codereview.chromium.org/1527203002
Cr-Commit-Position: refs/heads/master@{#33481}
Change the interpreter to always store the current context in the frame's
context slot instead of the function context. This makes it possible to
restore the correct context during deopt.
BUG=v8:4678,v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1604923002
Cr-Commit-Position: refs/heads/master@{#33477}
* Treat Select nodes as escaping
* Correctly void virtual field information
after a store to a non-const index
* Add a shortcut if all allocates escape
* Add a shortcut if no allocates are discovered
* Only reduce FrameState/StateValues nodes if they
have virtual allocates as input (transitively)
* Fix bug in FrameState/StateValues duplication
* Add check to verifier: First 3 inputs of FrameState
must be StateValues
R=mstarzinger@chromium.org
BUG=v8:4586
LOG=n
Review URL: https://codereview.chromium.org/1583213003
Cr-Commit-Position: refs/heads/master@{#33406}
o Adds wide variants of bytecodes that have operands describing ranges
of registers. The upcoming wide register support does not suppport
re-mapping ranges.
o Adds kRegPair16 and kRegTriple16 operands required for new wide
bytecodes and renames Count8/Count16 operands to RegCount8/RegCount16.
o Removes Exchange bytecodes
BUG=v8:4675
LOG=NO
Review URL: https://codereview.chromium.org/1595103006
Cr-Commit-Position: refs/heads/master@{#33389}
Make ForInPrepare take a kRegTriple8 operand and ForInNext take kRegPair8
operand for cache state. This is to ensure that the cache state output of
ForInPrepare is in consecutive registers to allow us to deopt the
ForInPrepare node from TF->Ignition (to be done in a followup CL).
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1584813002
Cr-Commit-Position: refs/heads/master@{#33357}
This bug improves performance of escape analysis.
* A allocation discovery phase (EscapeAnalysis::AssignAliases)
ensures compact representation of virtual state
* Node revisiting in EscapeStatusAnalysis has been improved
* Escape analysis no longer requires a trimmed graph
BUG=v8:4586
LOG=n
Review URL: https://codereview.chromium.org/1559123003
Cr-Commit-Position: refs/heads/master@{#33267}
Adds support for calling runtime functions which return a pair of
values. Adds the bytecode CallRuntimePair. Also adds support to TurboFan
for calling stubs which return multiple values.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1568493002
Cr-Commit-Position: refs/heads/master@{#33181}
Deopt support is added on two levels. On the IR level,
a new ObjectState node is added, which represenents an
object to be materialized. ObjectState nodes appear as
inputs of FrameState and StateValues nodes. On the
instruction select/code-generation level, the
FrameStateDescriptor class handles the nesting
introduced by ObjectState, and ensures that deopt code
with CAPTURED_OBJECT/DUPLICATED_OBJECT entries are
generated similarly to what crankshaft's escape
analysis does.
Two unittests test correctness of the IR level implementation.
Correctness for instruction selection / code generation
is tested by mjsunit tests.
R=jarin@chromium.org,mstarzinger@chromium.org
BUG=v8:4586
LOG=n
Review URL: https://codereview.chromium.org/1485183002
Cr-Commit-Position: refs/heads/master@{#33115}
New bytecodes for making registers with indicies wider than 1-byte
accessible.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1555713002
Cr-Commit-Position: refs/heads/master@{#33091}
According to the ES2015 specification, bound functions are exotic
objects, and thus don't need to be implemented as JSFunctions. So
we introduce a new JSBoundFunction type to represent bound functions
and make them optimizable. This already improves the performance of
calling or constructing bound functions by 10-100x depending on the
use case because we avoid the crazy dance between JavaScript and C++
that was implemented in v8natives.js previously.
There's still room for improvement in the performance of actually
creating bound functions, which is also relevant in practice, but
we already have a plan how to accomplish that later.
The mips/mips64 ports were contributed by akos.palfi@imgtec.com.
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
BUG=chromium:535408, chromium:571299, v8:4629
LOG=n
Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2
Cr-Commit-Position: refs/heads/master@{#33042}
Review URL: https://codereview.chromium.org/1542963002
Cr-Commit-Position: refs/heads/master@{#33044}
Reason for revert:
Breaks arm64 sim nosnap: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20nosnap%20-%20debug/builds/805/steps/Check/logs/function-bind
Original issue's description:
> [runtime] Introduce dedicated JSBoundFunction to represent bound functions.
>
> According to the ES2015 specification, bound functions are exotic
> objects, and thus don't need to be implemented as JSFunctions. So
> we introduce a new JSBoundFunction type to represent bound functions
> and make them optimizable. This already improves the performance of
> calling or constructing bound functions by 10-100x depending on the
> use case because we avoid the crazy dance between JavaScript and C++
> that was implemented in v8natives.js previously.
>
> There's still room for improvement in the performance of actually
> creating bound functions, which is also relevant in practice, but
> we already have a plan how to accomplish that later.
>
> The mips/mips64 ports were contributed by akos.palfi@imgtec.com.
>
> CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
> BUG=chromium:535408, chromium:571299, v8:4629
> LOG=n
>
> Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2
> Cr-Commit-Position: refs/heads/master@{#33042}
TBR=cbruni@chromium.org,hpayer@chromium.org,yangguo@chromium.org,akos.palfi@imgtec.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:535408, chromium:571299, v8:4629
Review URL: https://codereview.chromium.org/1552473002
Cr-Commit-Position: refs/heads/master@{#33043}
According to the ES2015 specification, bound functions are exotic
objects, and thus don't need to be implemented as JSFunctions. So
we introduce a new JSBoundFunction type to represent bound functions
and make them optimizable. This already improves the performance of
calling or constructing bound functions by 10-100x depending on the
use case because we avoid the crazy dance between JavaScript and C++
that was implemented in v8natives.js previously.
There's still room for improvement in the performance of actually
creating bound functions, which is also relevant in practice, but
we already have a plan how to accomplish that later.
The mips/mips64 ports were contributed by akos.palfi@imgtec.com.
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
BUG=chromium:535408, chromium:571299, v8:4629
LOG=n
Review URL: https://codereview.chromium.org/1542963002
Cr-Commit-Position: refs/heads/master@{#33042}
Move replacements out of virtual object. Replacements are
global to the graph and are not dependent on the virtual
state (after they are discovered).
R=mstarzinger@chromium.org
BUG=v8:4586
LOG=n
Review URL: https://codereview.chromium.org/1527533002
Cr-Commit-Position: refs/heads/master@{#32838}
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}
Nowadays, representation inference and simplified lowering can insert the
right truncations based on the use.
Review URL: https://codereview.chromium.org/1512243002
Cr-Commit-Position: refs/heads/master@{#32747}
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}
Extract ToBoolean hints from the fullcodegen code object and put them
into the ToBoolean nodes created by the AstGraphBuilder. We currently
do not yet consume this feedback, that will be done in a followup CL.
R=mstarzinger@chromium.org
BUG=v8:4583
LOG=n
Review URL: https://codereview.chromium.org/1494973002
Cr-Commit-Position: refs/heads/master@{#32576}
This moves the proper handling for the end node withing the constructed
graph into the RawMachineAssembler. This simplifies all assemblers and
makes the handling of {Start} and {End} symmetrical.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1493963003
Cr-Commit-Position: refs/heads/master@{#32563}
Also remove the ResultMode from ToBooleanStub and always return true or
false and use the same mechanism in fullcodegen. This is in preparation
for adding ToBoolean hints to TurboFan.
Drive-by-fix: We can use the power of the ToBooleanIC in TurboFan now
that the ResultMode is gone (and the runtime always returns true or
false from the miss handler).
R=mstarzinger@chromium.org
BUG=v8:4583
LOG=n
Review URL: https://codereview.chromium.org/1491223002
Cr-Commit-Position: refs/heads/master@{#32524}
We can constant fold %_IsJSReceiver(x) based on whether x is always a
receiver or can never be a receiver. This is important as
%_IsJSReceiver is inserted by the JSInliner.
R=jarin@chromium.org
BUG=v8:4544
LOG=n
Review URL: https://codereview.chromium.org/1486383003
Cr-Commit-Position: refs/heads/master@{#32519}
This is the first part of escape analysis for turbofan.
At the moment, there is no deopt support, and support
for loops is partial (only binary Phis are handled).
The CL includes 4 unittests.
There are also 8 new mjsunit tests, some of which are
skiped as they require features not yet implemented.
BUG=v8:4586
LOG=n
Review URL: https://codereview.chromium.org/1457683003
Cr-Commit-Position: refs/heads/master@{#32498}
