Rebuilding (after touching certain files) is crazy slow because
includes are out of control.
Fixing it:
- Don't include stuff in headers unless necessary.
- Include the stuff you need, not some other stuff that happens to include the
stuff you need.
BUG=v8:5294
Review-Url: https://codereview.chromium.org/2268303002
Cr-Commit-Position: refs/heads/master@{#38818}
With --ignition-preserve-bytecode, we don't have the guarantee that
SharedFunctionInfo::abstract_code() returns the code we deopt to.
R=mstarzinger@chromium.org
BUG=v8:5265
Review-Url: https://codereview.chromium.org/2239773003
Cr-Commit-Position: refs/heads/master@{#38614}
So far TurboFan wasn't adding the deoptimization reasons for eager/soft
deoptimization exits that can be used by either the DevTools profiler or
the --trace-deopt flag. This adds basic support for deopt reasons on
Deoptimize, DeoptimizeIf and DeoptimizeUnless nodes and threads through
the reasons to the code generation.
Also moves the DeoptReason to it's own file (to resolve include cycles)
and drops unused reasons.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2161543002
Cr-Commit-Position: refs/heads/master@{#37823}
This speeds up .bind by >10x as measured by
function f(a,b,c) {}
for (var i = 0; i < 10000000; i++) {
f.bind(1); // or more arguments.
}
(Uses hydrogen-stubs rather than TF due to var-args + possible runtime fallback, which is still unsupported in TF.)
BUG=
Review-Url: https://codereview.chromium.org/2044113002
Cr-Commit-Position: refs/heads/master@{#36817}
In order to support compiling to baseline on return we need to be able to
return to the actual return address. With this change this is what the
Return bytecode now does, removing the need for the
InterpreterExitTrampoline.
This change also removes the InterpreterNotifyDeoptXXX builtins and
unifies FCG and Igntion to both use NotifyDeoptXXX. As part of this
change, FullCodegenerator::State is moved to Deoptimize::BailoutState.
BUG=v8:4280
LOG=N
Committed: https://crrev.com/34c9626e2ee56fe805de549697ca5323aed7cb66
Cr-Commit-Position: refs/heads/master@{#36288}
Review-Url: https://codereview.chromium.org/1969423002
Cr-Commit-Position: refs/heads/master@{#36310}
Reason for revert:
Breaks
https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm%20-%20sim/builds/619
Might only affect pure release builds?
Original issue's description:
> [Interpreter] Remove InterpreterExitTrampoline and replace with returning to the entry trampoline.
>
> In order to support compiling to baseline on return we need to be able to
> return to the actual return address. With this change this is what the
> Return bytecode now does, removing the need for the
> InterpreterExitTrampoline.
>
> This change also removes the InterpreterNotifyDeoptXXX builtins and
> unifies FCG and Igntion to both use NotifyDeoptXXX. As part of this
> change, FullCodegenerator::State is moved to Deoptimize::BailoutState.
>
> BUG=v8:4280
> LOG=N
>
> Committed: https://crrev.com/34c9626e2ee56fe805de549697ca5323aed7cb66
> Cr-Commit-Position: refs/heads/master@{#36288}
TBR=mstarzinger@chromium.org,oth@chromium.org,rmcilroy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4280
Review-Url: https://codereview.chromium.org/1986353002
Cr-Commit-Position: refs/heads/master@{#36294}
In order to support compiling to baseline on return we need to be able to
return to the actual return address. With this change this is what the
Return bytecode now does, removing the need for the
InterpreterExitTrampoline.
This change also removes the InterpreterNotifyDeoptXXX builtins and
unifies FCG and Igntion to both use NotifyDeoptXXX. As part of this
change, FullCodegenerator::State is moved to Deoptimize::BailoutState.
BUG=v8:4280
LOG=N
Review-Url: https://codereview.chromium.org/1969423002
Cr-Commit-Position: refs/heads/master@{#36288}
This makes the profiler reconstruct inlined function frames at eager
deopt points from the deoptimization data. The main goal of this is to
remove the last side-channel where Crankshaft communicates directly to
the profiler. This is the last preparatory step towards deprecating the
side-channel in question.
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/1973993002
Cr-Commit-Position: refs/heads/master@{#36229}
This passes the inlining_id of deoptimization points via the relocation
info instead of via a side-channel to the CPU profiler. This is one step
towards deprecating the side-channel in question and avoid the need for
performing a lookup of the return address of the deopt point.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/1956693002
Cr-Commit-Position: refs/heads/master@{#36177}
In case when F was called with incompatible number of arguments (and therefore
the arguments adator frame was created), F inlines a tail call of G which then
deopts the deoptimizer should also remove the arguments adaptor frame for F.
This CL adds required machinery to the deoptimizer.
BUG=v8:4698
LOG=N
Review URL: https://codereview.chromium.org/1768263004
Cr-Commit-Position: refs/heads/master@{#34610}
This is a prerequisite for teaching deoptimizer to drop possible arguments adapter frame below current input frame which is needed to support tail call inlining.
Review URL: https://codereview.chromium.org/1761303002
Cr-Commit-Position: refs/heads/master@{#34533}
The support was already removed from the Crankshaft and this CL removes the last piece.
Review URL: https://codereview.chromium.org/1764593002
Cr-Commit-Position: refs/heads/master@{#34456}
This is mostly preparation for allowing the function closure to be materialized.
As a drive-by fix, I have added ignition source position support to the frame inspector (this fixed some ignition test failures).
Review URL: https://codereview.chromium.org/1698743002
Cr-Commit-Position: refs/heads/master@{#33975}
The idea here is to perform the handler lookup in the deoptimizer, and then take the information from the handler table to build the catch handler frame in the deoptimizer. Specifically, we use the pc offset, context location and stack height (in full-code) to tweak the output frame.
Sadly, this still requires nasty voodoo for the liveness analyzer so that it keeps variables alive if they are used in the catch handler.
Review URL: https://codereview.chromium.org/1416543006
Cr-Commit-Position: refs/heads/master@{#33936}
This removes uses of JSFunction by the (proper) deoptimizer. This will be useful
when we escape analyze JSFunction away. Unfortunately, the debugger still needs
JSFunction, so escape analysis would not work yet.
Review URL: https://codereview.chromium.org/1686183003
Cr-Commit-Position: refs/heads/master@{#33891}
JS_FRAME_FUNCTION can be expressed using the STACK_SLOT translation.
Review URL: https://codereview.chromium.org/1688023003
Cr-Commit-Position: refs/heads/master@{#33882}
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}
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}
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}
Adds support for generating deoptimization translations for interpreter
stack frames, and building interpreter frames for these translations
when a function deopts. Also adds builtins for
InterpreterNotifyDeoptimized which resume the function's continuation at
the correct point in the interpreter after deopt.
MIPS patch contributed by balazs.kilvady@igmtec.com
BUG=v8:4280
LOG=N
TEST=test-deoptimization.cc with --ignition and --turbo
Review URL: https://codereview.chromium.org/1528913003
Cr-Commit-Position: refs/heads/master@{#32971}
We can no longer just walk the prototype chain without doing proper access-checks. When installing a proxy as the __proto__ of the global object we might accidentally end up invoking cross-realm code without access-checks (see proxies-cross-realm-ecxeption.js).
Review URL: https://codereview.chromium.org/1521953002
Cr-Commit-Position: refs/heads/master@{#32903}
It's expensive to walk all shared function infos during the gc atomic
pause. Instead, use WeakCells to implement this structure without
manual clearing.
Reland due to a bug when reusing entries in the optimized code map.
BUG=
Review URL: https://codereview.chromium.org/1508703002
Cr-Commit-Position: refs/heads/master@{#32696}
It's expensive to walk all shared function infos during the gc atomic pause. Instead, use WeakCells to implement this structure without manual clearing.
BUG=
Review URL: https://codereview.chromium.org/1478943003
Cr-Commit-Position: refs/heads/master@{#32567}
The optimized code generated by Crankshaft cannot properly deal
with proxies (in the prototype chain), and there's probably no
point in trying to make that work^Wfast with Crankshaft at all.
TurboFan will handle that properly; Crankshaft just bails out
to fullcodegen, which then goes to the runtime, which should do
the right thing soon.
BUG=v8:1543
LOG=n
Review URL: https://codereview.chromium.org/1492983002
Cr-Commit-Position: refs/heads/master@{#32539}
Previously, it was not possible to specify StackSlotOperands for all
slots in both the caller and callee stacks. Specifically, the region
of the callee's stack including the saved return address, frame
pointer, function pointer and context pointer could not be addressed
by the register allocator/gap resolver.
In preparation for better tail call support, which will use the gap
resolver to reconcile outgoing parameters, this change makes it
possible to address all slots on the stack, because slots in the
previously inaccessible dead zone may become parameter slots for
outgoing tail calls. All caller stack slots are accessible as they
were before, with slot -1 corresponding to the last stack
parameter. Stack slot indices >= 0 access the callee stack, with slot
0 corresponding to the callee's saved return address, 1 corresponding
to the saved frame pointer, 2 corresponding to the current function
context, 3 corresponding to the frame marker/JSFunction, and slots 4
and above corresponding to spill slots.
The following changes were specifically needed:
* Frame has been changed to explicitly manage three areas of the
callee frame, the fixed header, the spill slot area, and the
callee-saved register area.
* Conversions from stack slot indices to fp offsets all now go through
a common bottleneck: OptimizedFrame::StackSlotOffsetRelativeToFp
* The generation of deoptimization translation tables has been changed
to support the new stack slot indexing scheme. Crankshaft, which
doesn't support the new slot numbering in its register allocator,
must adapt the indexes when creating translation tables.
* Callee-saved parameters are now kept below spill slots, not above,
to support saving only the optimal set of used registers, which is
only known after register allocation is finished and spill slots
have been allocated.
Review URL: https://codereview.chromium.org/1261923007
Cr-Commit-Position: refs/heads/master@{#30224}
This is the first step of turning the v8.h file into a normal header
instead of an include-the-world header. The new rule is that no other
header files are allowed to include v8.h, which is enforced by DEPS.
Also the number of includes inside the v8.h file has been drastically
reduced. Basically the last missing piece is the inclusion of the big
objects-inl.h file.
This in turn makes many headers follow the IWYU principle.
R=bmeurer@chromium.org,hpayer@chromium.org,titzer@chromium.org
Review URL: https://codereview.chromium.org/1282503003
Cr-Commit-Position: refs/heads/master@{#30102}
The calculation now takes into account the size of the arguments object
if it is present in the optimized frame.
(Yang, many thanks for the awesome repro!)
BUG=chromium:514362
LOG=N
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1264483008
Cr-Commit-Position: refs/heads/master@{#29973}
This is the initial (big) step towards a more uniform implementation of
the ToObject abstract operation (ES6 7.1.13), where we have a fallback
implementation in JSReceiver::ToObject() and a fast (hydrogen) CodeStub
to deal with the fast case (we should be able to do more cleanup on this
in a followup CL). For natives we expose the abstract operation via a
%_ToObject intrinsic, also exposed via a macro TO_OBJECT, that unifies
the previous confusion with TO_OBJECT_INLINE, ToObject, TO_OBJECT,
$toObject and %$toObject. Now the whole implementation of the abstract
operation is context independent, meaning we don't need any magic in the
builtins object nor the native context.
R=mvstanton@chromium.org,yangguo@chromium.org
Review URL: https://codereview.chromium.org/1266013006
Cr-Commit-Position: refs/heads/master@{#29953}
The only right way to enable access checks is to install access check callbacks on an object template via v8::ObjectTemplate::SetAccessCheckCallbacks(). It does not make sense to enable access checks on an arbitrary object.
Review URL: https://codereview.chromium.org/1217893012
Cr-Commit-Position: refs/heads/master@{#29439}
The remaining uses need some non-mechanical work:
* non-standard-layout type, probably due to mixed access control
* extended field designators
Review URL: https://codereview.chromium.org/1173343006
Cr-Commit-Position: refs/heads/master@{#29071}
