Reason for revert:
It is not a good idea to call CallICStub from the builtin. It might be sensitive to the frame structure. Constructing a internal frame might cause problems. It is much better to inline the code related to the type feedback vector into the builtin.
Original issue's description:
> [Interpreter] Implements calls through CallICStub in the interpreter.
>
> Calls are implemented through CallICStub to collect type feedback. Adds
> a new builtin called InterpreterPushArgsAndCallIC that pushes the
> arguments onto stack and calls CallICStub.
>
> Also adds two new bytecodes CallIC and CallICWide to indicate calls have to
> go through CallICStub.
>
> MIPS port contributed by balazs.kilvady.
>
> BUG=v8:4280, v8:4680
> LOG=N
>
> Committed: https://crrev.com/20362a2214c11a0f2ea5141b6a79e09458939cec
> Cr-Commit-Position: refs/heads/master@{#34244}
TBR=rmcilroy@chromium.org,mvstanton@chromium.org,mstarzinger@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4280, v8:4680
Review URL: https://codereview.chromium.org/1731253003
Cr-Commit-Position: refs/heads/master@{#34252}
Calls are implemented through CallICStub to collect type feedback. Adds
a new builtin called InterpreterPushArgsAndCallIC that pushes the
arguments onto stack and calls CallICStub.
Also adds two new bytecodes CallIC and CallICWide to indicate calls have to
go through CallICStub.
MIPS port contributed by balazs.kilvady.
BUG=v8:4280, v8:4680
LOG=N
Review URL: https://codereview.chromium.org/1688283003
Cr-Commit-Position: refs/heads/master@{#34244}
Removes some cctest and mjsunit test skips on Ignition for tests that now pass.
BUG=v8:4680
LOG=N
Review URL: https://codereview.chromium.org/1703563002
Cr-Commit-Position: refs/heads/master@{#34045}
Fixes a bug in Ignition on Arm64 where lr gets trashed in StaContextSlot
which causes the stack walker to get confused and crash.
BUG=v8:4680
LOG=N
Review URL: https://codereview.chromium.org/1694263002
Cr-Commit-Position: refs/heads/master@{#34016}
Adds support for ES6 super keyword and performing loads, stores, and
calls to super class members.
Implements SetHomeObject and enables ThisFunctionVariable.
BUG=v8:4280,v8:4682
LOG=N
Review URL: https://codereview.chromium.org/1689573004
Cr-Commit-Position: refs/heads/master@{#33977}
The tests in question have been disabled because throwing into lazy
deoptimized code was borked. After recent fixes landed these tests
should now pass again.
R=jarin@chromium.org
TEST=cctest/test-run-deopt/DeoptExceptionHandler
BUG=v8:4195
LOG=n
Review URL: https://codereview.chromium.org/1692873002
Cr-Commit-Position: refs/heads/master@{#33937}
Remove some Ignition skips in mjsunit and cctest, and replace a few
others with fails now that the there is more debugger support.
BUG=v8:4680
LOG=N
Review URL: https://codereview.chromium.org/1689993002
Cr-Commit-Position: refs/heads/master@{#33932}
Do not rely on elapsed time to collect enough samples.
Use CollectSample API function instead.
Remove checks for extra functions present in a profile, as
there in fact can be lots of native support functions.
BUG=v8:2999
LOG=N
Review URL: https://codereview.chromium.org/1665303004
Cr-Commit-Position: refs/heads/master@{#33822}
Adds implementation and tests to support const/let variables in the
interpreter.
BUG=v8:4280,v8:4679
LOG=N
Review URL: https://codereview.chromium.org/1634153002
Cr-Commit-Position: refs/heads/master@{#33819}
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}
There might be several ExternalCallbackScope's created
during the native callback. Remove the assert that is not
aligned with that.
Moreover this iterator must work for any kind of
stacks including corrupted ones.
BUG=v8:4705
LOG=N
Review URL: https://codereview.chromium.org/1663193003
Cr-Commit-Position: refs/heads/master@{#33751}
(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}
Removes skips for two tests in cctest that are no longer crashing with ignition.
BUG=v8:4680
LOG=N
Review URL: https://codereview.chromium.org/1668843003
Cr-Commit-Position: refs/heads/master@{#33732}
Moves the stack check from the function entry trampoline to instead be
after function activation using an explicit StackCheck bytecode. Also
add stack checks on back edges of loops.
BUG=v8:4280,v8:4678
LOG=N
Review URL: https://codereview.chromium.org/1665853002
Cr-Commit-Position: refs/heads/master@{#33730}
This removes --harmony-completion, --harmony-concat-spreadable, and
--harmony-tolength and moves the appropriate tests from harmony/ to es6/.
Review URL: https://codereview.chromium.org/1667453002
Cr-Commit-Position: refs/heads/master@{#33712}
Skips cctest/test-heap/NoWeakHashTableLeakWithIncrementalMarking
that is crashing on arm64.
BUG=v8:4280
LOG=N
NOTRY=true
Review URL: https://codereview.chromium.org/1660613005
Cr-Commit-Position: refs/heads/master@{#33708}
Adds implementation and tests for with statement to interprter.
BUG=v8:4280,v8:4684
LOG=N
Review URL: https://codereview.chromium.org/1656863002
Cr-Commit-Position: refs/heads/master@{#33705}
This clears the currently pending message object whenever a try-block or
a finally-block is being entered in interpreted code. The intention is
to avoid memory leaks introduced by the message object. Also the message
object is being restored when a finally-block exits.
R=rmcilroy@chromium.org
TEST=cctest/test-heap/MessageObjectLeak
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1651993002
Cr-Commit-Position: refs/heads/master@{#33704}
Also changes SKIP to FAIL to ensure we know when we have fixed a test.
BUG=v8:4280,v8:4680
LOG=N
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_arm64_dbg,v8_linux_arm_dbg
Review URL: https://codereview.chromium.org/1656803002
Cr-Commit-Position: refs/heads/master@{#33665}
Set the bytecode array correctly in Runtime_SetCode.
This fixes issues with building the snapshot with ignition enabled.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1647913002
Cr-Commit-Position: refs/heads/master@{#33638}
The previous versions of Math.max and Math.min made it difficult to
optimize those (that's why we already have custom code in Crankshaft),
and due to lack of ideas what to do about the variable number of
arguments, we will probably need to stick in special code in TurboFan
as well; so inlining those builtins is off the table, hence there's no
real advantage in having them around as "not quite JS" with extra work
necessary in the optimizing compilers to still make those builtins
somewhat fast in cases where we cannot inline them (also there's a
tricky deopt loop in Crankshaft related to Math.min and Math.max, but
that will be dealt with later).
So to sum up: Instead of trying to make Math.max and Math.min semi-fast
in the optimizing compilers with weird work-arounds support %_Arguments
%_ArgumentsLength, we do provide the optimal code as native builtins
instead and call it a day (which gives a nice performance boost on some
benchmarks).
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1641083003
Cr-Commit-Position: refs/heads/master@{#33582}
This translates the exception handler table attached to a bytecode array
correctly into exceptional projections within the TurboFan graph. We
perform an abstract simulation of handlers that are being entered and
exited by the bytecode iteration to track the correct handler for each
node.
R=oth@chromium.org
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1641723002
Cr-Commit-Position: refs/heads/master@{#33580}
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}
This ensures that the BytecodeGraphBuilder can generate correct graphs
even when deoptimization has not been enabled. This configuration is not
enabled in production, and we might eventually decide to deprecate it
for good. Until then, this is a quick fix.
R=jarin@chromium.org
TEST=cctest/test-pipeline
Review URL: https://codereview.chromium.org/1640683002
Cr-Commit-Position: refs/heads/master@{#33545}
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}
This fixes the translation of 'throw' bytecodes to TurboFan graphs. The
correct runtime function is being used now, also the frame states are
attached to the correct nodes now.
R=mythria@chromium.org
TEST=cctest/test-run-jsexceptions/ThrowMessageIndirectly
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1636033002
Cr-Commit-Position: refs/heads/master@{#33513}
Adds support for calling native function literals. Moves the logic for building
the native function's SharedFunctionInfo out of full-codegen into compiler.cc
to allow it to be shared between fullcodegen and Ignition.
BUG=v8:4686
LOG=N
Review URL: https://codereview.chromium.org/1635553002
Cr-Commit-Position: refs/heads/master@{#33510}
The current support for try-catch in the interpreter can handle most of
the cases appearing in our test suite. Also the flag in question did not
detect try-finally constructs. This removes the flag and instead extends
the test expectations.
R=rmcilroy@chromium.org
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1631593003
Cr-Commit-Position: refs/heads/master@{#33494}
These tests have been disabled while support for try-finally was work in
progress. By now control flow is connected properly and the tests pass.
R=oth@chromium.org
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1626503002
Cr-Commit-Position: refs/heads/master@{#33474}
This implements a first prototype of stack unwinding for interpreted
frames. The unwinding machinery performs a range-based lookup in the
given handler table and potentially continues dispatching at the handler
offset. Note that this does not yet correctly restore the context to the
correct value when the handler is being entered.
R=rmcilroy@chromium.org,oth@chromium.org
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1605633003
Cr-Commit-Position: refs/heads/master@{#33414}
