This enables eager optimization of top-level code with TurboFan and
extends test coverage by triggering it with the --always-opt flag.
Script contexts are now also properly allocated in TurboFan.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1053063003
Cr-Commit-Position: refs/heads/master@{#27633}
Also fix Debug.showBreakPoints for multiple break points at the same location.
BUG=v8:3960
LOG=N
Review URL: https://codereview.chromium.org/998253005
Cr-Commit-Position: refs/heads/master@{#27444}
This removes the CompilationInfoWithZone class from the header file
because it is more than a pure convenience class and shouldn't be used
outside of the compiler at all.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1000353004
Cr-Commit-Position: refs/heads/master@{#27411}
it is the last patch of https://codereview.chromium.org/1012633002
All that we need here is to push the collected info to the profiler
and convert it into actionable information about deopt.
On the Next: get the info accessible by embedder.
BUG=chromium:452067
LOG=n
TEST=DeoptAtFirstLevelInlinedSource, DeoptAtSecondLevelInlinedSource, DeoptUntrackedFunction
Review URL: https://codereview.chromium.org/1013143003
Cr-Commit-Position: refs/heads/master@{#27403}
Use a delegating constructor for CompilationInfo, reducing duplicated
code. Simplified handling of InlinedFunctionInfos on the way: When we
start compiling, we have bigger things to worry about than a default
vector.
Reduced the usage of a SharedFunctionInfo for compiling, this is a
slighty strange concept.
Review URL: https://codereview.chromium.org/1018853004
Cr-Commit-Position: refs/heads/master@{#27299}
This is the fifth part of https://codereview.chromium.org/1012633002
In this part we collect the offsets of deopt calls and save it into
an inlined function info.
On the Next:
Later when deopt happens we will get the offset of deopt call and
search it among inlined infos.
BUG=chromium:452067
LOG=n
Review URL: https://codereview.chromium.org/1011113004
Cr-Commit-Position: refs/heads/master@{#27258}
this is the second part of https://codereview.chromium.org/1012633002.
almost mechanical change.
I'd like to enable positions tracking when cpu profiler is working.
But I'll switch it on for cpu-profiler in another patch.
BUG=chromium:452067
LOG=n
Review URL: https://codereview.chromium.org/995183005
Cr-Commit-Position: refs/heads/master@{#27224}
The per-isolate compilation cache is a lot faster still than
the serialized code cache. Promote code to compilation cache
after deserialization.
R=vogelheim@chromium.org
BUG=chromium:399580
LOG=N
Review URL: https://codereview.chromium.org/1008363002
Cr-Commit-Position: refs/heads/master@{#27220}
I did some investigation and found that in the most cases
the old schema with the separate List for functions and inlines
gives us no memory benefits because more frequently we inlines
different functions into parent function. So the plain schema
wins a tens or even hundreds bytes a few thousand times.
The only drawback is that we will print the inlined body
the each time when we inline it. But is not a problem
because it happens only under FLAG_hydrogen_track_positions.
Also I added script_id to the structure, so it could be used later
by cpu-profiler.
BUG=chromium:452067
LOG=n
Review URL: https://codereview.chromium.org/996153003
Cr-Commit-Position: refs/heads/master@{#27134}
Rationale: separate the inputs and outputs of parsing + analysis from the business of compiling (i.e. generating machine code).
BUG=
Review URL: https://codereview.chromium.org/974213002
Cr-Commit-Position: refs/heads/master@{#27078}
We mark certain builtins for inlining, and those should always be
inlined into optimized code (CrankShaft already handles it this way), so
we should support that in TurboFan as well. Currently this mainly
affects a certain set of Math functions, but once have the basics in
place we can extend this to any kind of builtin/code stub/accessor.
This adds a new flag --turbo_builtin_inlining (enabled by default), that
forces the inliner to always inline builtins marked for inlining, but
does not affect inlining of other functions (this is still controlled by
the --turbo-inlining flag).
BUG=v8:3952
LOG=n
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/993473002
Cr-Commit-Position: refs/heads/master@{#27059}
Internal references are absolute addresses into the instruction
stream. Turn them into relative addresses when serializing and
back when deserializing to keep them valid.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/976623002
Cr-Commit-Position: refs/heads/master@{#27020}
According to Source Map specification [1] source map url can be passed either as a magic comment at the end of script or as SourceMap http header. We already parse the former value and expose it on Script object. This change allows to unify the way we deal with source map urls received in http header by providing api for passing that url into the script being compiled.
source_map_url is intentionally not passed into CompilationCacheScript::Lookup. The cache is anyways disabled when debugger is on.
[1] https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit
LOG=Y
BUG=chromium:462572
Review URL: https://codereview.chromium.org/983603003
Cr-Commit-Position: refs/heads/master@{#27017}
TryInline needed position only for the case when we track positions.
We can drop the position argument and use the current position from GraphBuilder.
The only problem that it doesn't match with the inline point.
The reason of that was the fact that builder had moved the position forward by
visiting arguments expressions.
I fixed this by restoring the current positon in HOptimizedGraphBuilderWithPositions::Visit*
BUG=452067
LOG=n
Review URL: https://codereview.chromium.org/962593005
Cr-Commit-Position: refs/heads/master@{#26953}
A function could be deoptimized due to a deopt in the inlined code.
The inlined function might be defined in another script. So we need to
track the information about the inlined functions (scriptId and offset).
We already have the tracking code which is behind FLAG_hydrogen_track_position.
So as the first step we need to make the info accessible by CPU profiler.
In the follow-up patches I'll add the code which will enable position
tracking and push the info into CodeEntry entries.
BUG=452067
LOG=n
Review URL: https://codereview.chromium.org/914413007
Cr-Commit-Position: refs/heads/master@{#26680}
Parser must be able to operate independent of Isolate and the V8 heap during
parsing. After the heap-independent phase, there is a heap dependent phase,
during which we internalize strings, handle errors, etc.
This makes Isolate (also via CompilationInfo) unaccessible during parsing, and
thus decreases the probability of accidental code changes which would add
heap-dependent operations into the heap-independent phase.
Since Isolate is also accessible via CompilationInfo, now CompilationInfo is
only passed to the entry points of parsing, and not stored in Parser.
R=rossberg@chromium.org
BUG=
Review URL: https://codereview.chromium.org/908173003
Cr-Commit-Position: refs/heads/master@{#26612}
Use a fake code stub instead, basically following the null object pattern.
Review URL: https://codereview.chromium.org/918973002
Cr-Commit-Position: refs/heads/master@{#26610}
This adds an "experimental" API hook (v8::ScriptCompiler::CompileModule)
allowing compilation of modules. The code gen is incredibly basic: the
module body is represented by a Block in the AST. But this at least gets
more of the pipeline working, and opens the door to writing mjsunit tests
(once d8 is modified to support module compilation).
BUG=v8:1569
LOG=n
Review URL: https://codereview.chromium.org/902093002
Cr-Commit-Position: refs/heads/master@{#26496}
It doesn't do anything for now, but it implies strict mode. Added tests to
test-parsing.cc to test that.
BUG=
Review URL: https://codereview.chromium.org/898983002
Cr-Commit-Position: refs/heads/master@{#26460}
This enables adding more language modes in the future.
For maximum flexibility, LanguageMode is a bitmask, so we're not restricted to
use a sequence of language modes which are progressively stricter, but we can
express the language mode as combination of features.
For now, LanguageMode can only be "sloppy" or "strict", and there are
STATIC_ASSERTS in places which need to change when more modes are added.
LanguageMode is a bit like the old LanguageMode when "extended" mode was still
around (see https://codereview.chromium.org/8417035 and
https://codereview.chromium.org/181543002 ) except that it's transmitted through
all the layers (there's no StrictModeFlag).
BUG=
Review URL: https://codereview.chromium.org/894683003
Cr-Commit-Position: refs/heads/master@{#26419}
If a (pure) node has two or more uses, but there exists a path from the
common dominator of these uses to end, which does not contain a use,
then we split the node such that no unnecessary computation takes place.
Note however, that this only applies if the node cannot be hoisted out
of a loop.
BUG=v8:3864
LOG=n
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/899433005
Cr-Commit-Position: refs/heads/master@{#26404}
In DevTools we need one more flag for script origin - is debugger script. We already have "is shared origin" flag. The new flag added by analogy with the old but new has accessor in script object.
R=yurys@chromium.org
Review URL: https://codereview.chromium.org/879553002
Cr-Commit-Position: refs/heads/master@{#26324}
Along the way:
- Thread isolate parameter explicitly through code that used to
rely on getting it from the zone.
- Canonicalize the parameter position of isolate and zone for
affected code
- Change Hydrogen New<> instruction templates to automatically
pass isolate
R=mstarzinger@chromium.org
LOG=N
Review URL: https://codereview.chromium.org/868883002
Cr-Commit-Position: refs/heads/master@{#26252}
of running a script is really spent in compilation. That is, sum up the
total time spent compiling (parsing + compile proper) within a run call
as seen through the API.
@jochen: So many questions:
- Is it ok to re-use V8.CompileLazy?
This measures something a little different.
- clang-format does funny things to the huge macro definitions.
I accepted clang-format changes for all code, but reverted for
the #define orgies in counters.h. ok?
- Am I measuring the right thing. That is, are Aggregat[ing|ed]TimerScope
in the right place?
I'll fiddle a bit more with this to see if it does the right thing. Would
be happy if you could still review now-ish.
BUG=
Review URL: https://codereview.chromium.org/790413004
Cr-Commit-Position: refs/heads/master@{#26226}
This ensures that we always have a kind of "brace" around the actual compilation
with --trace-opt. Previously this was coupled to --trace-hydrogen for
Crankshaft, and there was no output at the start of the compilation for
TurboFan.
Removed redundant "[completed...]" output: Whenever the compilation was
successful, we have already printed "[optimizing...took...]".
Output total TurboFanning time with --trace-opt, too (basically as graph
building time, this is rather arbitrary).
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/819613002
Cr-Commit-Position: refs/heads/master@{#25900}
The %OptimizeFunctionOnNextCall sledgehammer can cause a function to be
marked for optimization before it's ever been compiled by fullcode.
This can lead to the situation where a function doesn't have optimization
disabled until we try to compile it optimized.
Basically, the assert should just handle this case more gracefully.
R=yangguo@chromium.org
BUG=436893
LOG=Y
Review URL: https://codereview.chromium.org/760063002
Cr-Commit-Position: refs/heads/master@{#25528}
