There is no reason to keep around the HOptimizedGraphBuilder after the
graph has successfully been built. Later phases in OptimizedCompileJob
should not rely on it anymore.
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/1756183002
Cr-Commit-Position: refs/heads/master@{#34440}
When we try to optimize a function with Crankshaft, but compilation
bails out, don't disable optimization for that function entirely,
just disable Crankshaft, so TurboFan will be used for the next attempt.
Thereby this widens the TurboFan intake valve.
Review URL: https://codereview.chromium.org/1751873002
Cr-Commit-Position: refs/heads/master@{#34396}
Adds support for cpu profiler logging to the interpreter. Modifies the
the API to be passed AbstractCode objects instead of Code objects, and
adds extra functions to AbstractCode which is required by log.cc and
cpu-profiler.cc.
The main change in sampler.cc is to determine if a stack frame is an
interpreter stack frame, and if so, use the bytecode address as the pc
for that frame. This allows sampling of bytecode functions. This
requires adding support to SafeStackIterator to determine if a frame is
interpreted, which we do by checking the PC against pre-stored addresses
for the start and end of interpreter entry builtins.
Also removes CodeDeleteEvents which are dead code and haven't
been reported for some time.
Still to do is tracking source positions which will be done in a
followup CL.
BUG=v8:4766
LOG=N
Review URL: https://codereview.chromium.org/1728593002
Cr-Commit-Position: refs/heads/master@{#34321}
This adds explicit setters for the SharedFunctionInfo::function_data
field. Such setters are safer because they allow for explicit checking
of which values are allowed, and they improve readability because the
intended semantics become clear for each call-site. Also fix a cctest
case along the way.
R=rmcilroy@chromium.org
Review URL: https://codereview.chromium.org/1730853005
Cr-Commit-Position: refs/heads/master@{#34297}
Up until now we were unable to (re)optimize code when we hit
uninitialized (Keyed)Load/StoreICs in the code. We always put an IC
there (sharing the feedback vector with fullcodegen at least) and called
it a day. But we never deoptimized the code object when we gathered more
feedback. This doesn't work very well in practice, esp. with hot code
relying on this. So until we have a proper mechanism to express the need
to reoptimize after we gathered additional feedback from optimized code,
we follow the Crankshaft approach instead and install a SOFT deopt, so
we can not only learn but also utilize the new feedback.
R=mstarzinger@chromium.org
BUG=v8:4470
LOG=n
Review URL: https://codereview.chromium.org/1518013002
Cr-Commit-Position: refs/heads/master@{#34178}
This CL adds a TRACE_EVENT where there is an isolated LOG, a HistogramTimer
or a TimerEvent.
Once we have a d8 tracing controller, all TimerEvents will be removed since
they do not provide an added value over TRACE_EVENTs. HistogramTimers will
remain, but their functionality will be limited to Histograms only.
BUG=v8:4562
LOG=N
Review URL: https://codereview.chromium.org/1707563002
Cr-Commit-Position: refs/heads/master@{#34099}
V8 tracks already most useful information, but lacks proper tracing scopes
that make it possible to distinguish certain events from each other.
- add trace-scope to track lazy-parsing due to optimization
- add trace-scope to track code optimization
BUG=
Review URL: https://codereview.chromium.org/1661883003
Cr-Commit-Position: refs/heads/master@{#34002}
The field in question is only needed when the optimizing compiler is
triggered via OSR. All other paths (e.g. from bytecode stream) should
not rely on the unoptimized code being present.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1685633002
Cr-Commit-Position: refs/heads/master@{#33860}
This makes sure we can run through the TurboFan pipeline without having
to parse the source when using the bytecode stream as input. This path
is now being tested by the BytecodeGraphTester helper.
R=titzer@chromium.org,rmcilroy@chromium.org
Review URL: https://codereview.chromium.org/1679313002
Cr-Commit-Position: refs/heads/master@{#33856}
The function in question can already return an empty handle in the case
of failures. This makes that contract explicit by using MaybeHandle like
all other compiler API functions.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1590963002
Cr-Commit-Position: refs/heads/master@{#33839}
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 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}
The motivation for this is that CompilationInfo really shouldn't
explicitly know anything about CodeStubs. This is evident in
the TurboFan stubs pipeline, which only needs to pass down
information about Code::Flags to the code generator and not
any of the CallInterfaceDescriptor silliness that Hydrogen has
to push around, since TF has the Linkage class that
encapsulates everything that is needed for the stub ABI. So,
instead of threading CodeStub machinery through the TF stub
pipeline, it is now removed from CompilationInfo and replaced
by only the explicit bits needed both by the Crankshaft and
TF pipelines in code generation.
Review URL: https://codereview.chromium.org/1604543002
Cr-Commit-Position: refs/heads/master@{#33410}
Now that we support eval in Ignition, remove the fallback for eval checks
and make the flag only fallback on catch blocks.
BUG=v8:4280,v8:4676
LOG=N
Review URL: https://codereview.chromium.org/1595223004
Cr-Commit-Position: refs/heads/master@{#33384}
This removes the need to pass in the current unoptimized code when
requesting optimized code for a function. Note that the notion of
unoptimized code becomes moot when optimizing from the interpreter
bytecode, hence the API should not encode such a dependency.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1588293005
Cr-Commit-Position: refs/heads/master@{#33353}
This splits out the SourcePosition class into a separate header file.
Reason for this refactoring is that said class is mostly used by the
Crankshaft compiler and not needed for all compilers. Also having the
assembler depend on the class creates a dependency cycle.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1581083009
Cr-Commit-Position: refs/heads/master@{#33325}
This restricts turbofan to turbofan-supported subset for the shipping
configuration ("use asm" and features unsupported by Crankshaft).
Without this, we compile with Turbofan even when there is
try-catch-finally as long as the function is "use asm" or
it contains a feature unsupported by crankshaft but supported
by turbofan (e.g., 'with' statement).
BUG=
Review URL: https://codereview.chromium.org/1552233002
Cr-Commit-Position: refs/heads/master@{#33085}
Use the same mechanism that is already available for Crankshaft to not
leak all kinds of things in TurboFan generated code. Long-term we will
support weakness in a better way, but for now, just use the
infrastructure that is already in place to avoid memory leaks via
TurboFan generated code.
R=jarin@chromium.org, ulan@chromium.org
Review URL: https://codereview.chromium.org/1555743003
Cr-Commit-Position: refs/heads/master@{#33073}
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}
This fixes a path in the compilation pipeline that side-stepped the
interpreter when a function literal was eagerly compiled. This caused
the interpreter to miss some test coverage.
R=rmcilroy@chromium.org
Review URL: https://codereview.chromium.org/1528853002
Cr-Commit-Position: refs/heads/master@{#32867}
This unifies the decision whether to use Ignition or FullCodeGenerator
to generate baseline code into a single place. This allows for small
function literals that are compiled eagerly to go through Ignition.
R=rmcilroy@chromium.org
Review URL: https://codereview.chromium.org/1525663002
Cr-Commit-Position: refs/heads/master@{#32848}
This removes the ability to generate stub code via the full-fledged
compiler pipeline that parses and analyzes JavaScript source code.
Generation of stub code has been moved to a lower-level entry point.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1520373002
Cr-Commit-Position: refs/heads/master@{#32847}
Moves all files related to AST and scopes into ast/,
and all files related to scanner & parser to parsing/.
Also eliminates a couple of spurious dependencies.
R=mstarzinger@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1481613002
Cr-Commit-Position: refs/heads/master@{#32351}
Adds a blacklist of tests which are currently unsupported or broken in Ignition to
the mjsunit and test262 test status.
Also removes --ignition-script-filter flag, and adds a
--ignition_fallback_on_eval_and_catch flag which fallsback to fullcodegen for
functions which call eval or contain a catch block.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1420963009
Cr-Commit-Position: refs/heads/master@{#31864}
The Interpreter uses the function_data slot in the shared function info, so
can't be used to compile functions which use that field for other reasons,
such as API functions or functions with builtin function ids.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1427143002
Cr-Commit-Position: refs/heads/master@{#31721}
Both the JSTypeFeedbackSpecializer and the JSTypeFeedbackLowering is
dead code by now, since the more general JSNativeContextSpecialization
deals with the property/global load/store type feedback in a way that
also interacts properly with inlining.
BUG=v8:4470
LOG=n
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1407913003 .
Cr-Commit-Position: refs/heads/master@{#31462}
This adds a bit of boilerplate to some AstVisitors (they now have to
declare their own zone_ member and zone() accessor), but makes it clearer
what DEFINE_AST_VISITOR_SUBCLASS_MEMBERS is for: stack limit checking.
Review URL: https://codereview.chromium.org/1394303008
Cr-Commit-Position: refs/heads/master@{#31287}
Add a flag to explicitly filter scripts in ignition and use it for the test262
variant. The previous approach of overloading ignition-filter meant that only
top-level code was getting compiled through ignition.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1396493002
Cr-Commit-Position: refs/heads/master@{#31164}
