- Thread Type::FunctionType through stubs and the TF pipeline.
- Augment Typer to decorate parameter nodes with types from
a Type::FunctionType associated with interface descriptors.
- Factor interface descriptors into platform-specific and
platform-independent components so that all descriptors share
a common Type::FunctionType for all platforms.
Review URL: https://codereview.chromium.org/1197703002
Cr-Commit-Position: refs/heads/master@{#29248}
Speculative revert in the hopes of fixing serializer crashes seen in canary.
This reverts commit c166945083, as well as
followup change "Do not look for existing shared function info when compiling a new script."
(commit 7c43967bb7).
BUG=chromium:503552,v8:4132
TBR=yangguo@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1207583002
Cr-Commit-Position: refs/heads/master@{#29241}
This fixes a terrible interaction of code flushing and the clearing of
optimized code maps hanging off a SharedFunctionInfo. The following is
what happened:
1) Incremental marking cleared map in SharedFunctionInfo s, however it
was not enqueued as a flushing candidate because one JSFunction f1
still had optimized code.
2) Deoptimization of f1 made s eligible for code flushing.
3) Optimization of f2 added new entry to optimized code map of s.
4) The JSFunction f2 became unreachable and hence is never marked.
5) Incremental marking now visits f1, finds it eligible for flushing,
also s is eligible for flushing, both are enqueued.
6) Marking finishes, code flusher clears f1 and s, but the optimized
code map of s still contains an entry.
7) Boom!
R=ulan@chromium.org,hpayer@chromium.org
TEST=mjsunit/es6/generators-iteration
BUG=v8:3803
LOG=N
Review URL: https://codereview.chromium.org/1197713004
Cr-Commit-Position: refs/heads/master@{#29177}
Each Script object now keeps a WeakFixedArray of SharedFunctionInfo
objects created from this script.
This way, when compiling a function, we do not create duplicate shared
function info objects when recompiling with either compiler.
This fixes a class of issues in the debugger, where we set break points
on one shared function info, but functions from duplicate shared function
infos are not affected.
LOG=N
BUG=v8:4132
Review URL: https://codereview.chromium.org/1183733006
Cr-Commit-Position: refs/heads/master@{#29151}
Reason for revert:
Breaks Windows debug.
Original issue's description:
> [turbofan] Record the SharedFunctionInfo of ALL inlined functions.
>
> Previously we only recorded the SharedFunctionInfo of inlined functions
> that had at least one (lazy) deopt point left at code generation time.
>
> R=mstarzinger@chromium.org
>
> Committed: ffa0b4007cTBR=mstarzinger@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1178683004
Cr-Commit-Position: refs/heads/master@{#28920}
Previously we only recorded the SharedFunctionInfo of inlined functions
that had at least one (lazy) deopt point left at code generation time.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1175953002.
Cr-Commit-Position: refs/heads/master@{#28919}
When compiling on a laptop I like to concatenate the small test files.
This makes a big difference to compile times. These changes make that
easier.
R=ulan@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1163803002
Cr-Commit-Position: refs/heads/master@{#28742}
This allows enabling TurboFan on a certain subset of language features
in the AstNumberingVisitor. The heuristics of when to optimize remain
unchanged, only the choice of which optimizing compiler to use changes.
R=bmeurer@chromium.org
BUG=v8:4131
LOG=N
Review URL: https://codereview.chromium.org/1155503002
Cr-Commit-Position: refs/heads/master@{#28544}
Replace the --turbo-deoptimization flag with --turbo-asm-deoptimization
and enable deoptimization for non-asm.js TurboFan code unconditionally.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1153483002
Cr-Commit-Position: refs/heads/master@{#28543}
This flag mostly duplicates SharedFunctionInfo::optimization_disabled
and is only queried in places where the original is available. Remove
the brittle and error-prone duplication.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1148043002
Cr-Commit-Position: refs/heads/master@{#28520}
When the page is controlled by a ServiceWorker, the ServiceWorker can return an opaque (non-CORS cross origin) resource response.
We need to treat the messages from such script resource as opaque.
Committed: https://crrev.com/7a599c5e1242d3c5ab7515ee149623da90ae69ec
Cr-Commit-Position: refs/heads/master@{#28445}
Review URL: https://codereview.chromium.org/1140673002
Cr-Commit-Position: refs/heads/master@{#28459}
When the page is controlled by a ServiceWorker, the ServiceWorker can return an opaque (non-CORS cross origin) resource response.
We need to treat the messages from such script resource as opaque.
Review URL: https://codereview.chromium.org/1140673002
Cr-Commit-Position: refs/heads/master@{#28445}
... and the following two
"PPC: Resolve references to "this" the same way as normal variables"
"Remove Scope::scope_uses_this_ flag"
R=hablich@chromium.org
BUG=chromium:487289
LOG=N
Review URL: https://codereview.chromium.org/1134003003
Cr-Commit-Position: refs/heads/master@{#28395}
This stub will be used as the basis of a Math.floor-specific CallIC to
detect and track calls to floor that return -0.
Along the way:
- Create a TurboFanCodeStub super class from which the StringLength and
MathRound TF stubs derive.
- Fix the ugly hack that passes the first stub parameter as the "this"
pointer in the the TF-compiled JS function.
- Fix bugs in the ia32/x64 disassembler.
Review URL: https://codereview.chromium.org/1137703002
Cr-Commit-Position: refs/heads/master@{#28339}
TurboFan compilation was committing dependencies long before the
optimized function made it's way into the optimized code list for
the native context. The problem is that once the code pointer is out
there in dependency arrays, it is eligible for deopt. But the deopt
logic needs the code to be in the optimized code list to fully do it's
job.
BUG=
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1136693003
Cr-Commit-Position: refs/heads/master@{#28312}
Reason for revert:
The reason for reverting is: [Sheriff] Need to fix compilation after this revert:
5cab6be83a
Original issue's description:
> Remove Scope::scope_uses_this_ flag
>
> Use of the "this" variable is now tracked using scopes, like any other variable.
>
> R=arv@chromium.org
> LOG=N
> BUG=
>
> Committed: https://crrev.com/afba55965118d9ba57e53c729f52be2340e626e0
> Cr-Commit-Position: refs/heads/master@{#28268}
TBR=arv@chromium.org,wingo@igalia.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1131713004
Cr-Commit-Position: refs/heads/master@{#28285}
long and trivial functions, so that they can be eagerly compiled after all.
This essentially allows the parser to renege on its earlier decision to
lazy-parse, if additional information suggests it was a bad decision.
BUG=chromium:470930
LOG=Y
Review URL: https://codereview.chromium.org/1102523003
Cr-Commit-Position: refs/heads/master@{#28252}
This CL contains the first steps towards tail call optimization:
* Structurally detect tail calls during instruction selection,
looking for special return/call combinations.
* Added new architecture-specific instructions for tail calls which
jump instead of call and take care of frame adjustment.
* Moved some code around.
Currently we restrict tail calls to callees which only use registers
for arguments/return value and to call sites which are explicitly
marked as being OK for tail calls. This excludes, among other things,
call sites in sloppy JS functions and our IC machinery (both need in
general to be able to access the caller's frame).
All this is behind a flag --turbo-tail-calls, which is currently off
by default, so it can easily be toggled.
Review URL: https://codereview.chromium.org/1108563002
Cr-Commit-Position: refs/heads/master@{#28150}
Given
FunctionLiteral* a; a->is_parenthesized()
const FunctionLiteral* b; b->is_parenthesized()
the first accesses FunctionLiteral::IsParenthesized, the second accesses Expression::IsParenthesizedField.
Since these are distinct uses, we could rename them based on their use:
- Expression::is_parenthesized -> is_single_parenthesized
Count # of parenthesis, for parsing & error handling:
no parenthesis -> single parenthesis -> multi parenthesis
- FunctionLiteral::eager_compile_hint()
Hint from parser to compiler about whether the parser suggests this function for eager compilation.
BUG=
Review URL: https://codereview.chromium.org/1097723005
Cr-Commit-Position: refs/heads/master@{#28042}
Now all nodes that care about deoptimization always take frame state
inputs no matter whether deoptimization is enabled for a particular
function. In case that deoptimization is off, the AstGraphBuilder just
inserts the empty frame state. This greatly simplifies the logic in
various places and makes testing easier as well, and is probably the
first step towards enabling --turbo-deoptimization by default.
There seems to be no noticable performance impact on asm.js programs.
Also fix the graph replay in order to regenerate the scheduler unittests.
Review URL: https://codereview.chromium.org/1106613003
Cr-Commit-Position: refs/heads/master@{#28026}
This allows loopy TurboFan code to be interrupted by placing a stack
check (i.e. JSStackCheck node) into each loop. Note that we currently
limit this to non-asm.js code. Also note that stack checks are actually
placed after loop headers and not at back-branches, which allows us to
reuse existing BailoutIds from Crankshaft.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1065923002
Cr-Commit-Position: refs/heads/master@{#27666}
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}
