This adds a shortcut to the compilation pipeline that makes sure we are
not regenerating bytecode when it has been preserved from a previous
request. This can happen when code flushing removes baseline code,
thereby clearing the entry trampoline but leaving bytecode intact.
R=yangguo@chromium.org
BUG=v8:5265
Review-Url: https://codereview.chromium.org/2241783002
Cr-Commit-Position: refs/heads/master@{#38620}
Also, re-enables the use of the type feedback in BytecodeGraphBuilder.
BUG=v8:5273
LOG=N
Review-Url: https://codereview.chromium.org/2235133003
Cr-Commit-Position: refs/heads/master@{#38618}
This removes some compiler internals as well as some JavaScript specific
helper from the CodeAssembler, by either hiding or moving the support
into the CodeStubAssembler.
R=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2246463002
Cr-Commit-Position: refs/heads/master@{#38617}
This should be faster and should give the same result.
BUG=v8:5203
Review-Url: https://codereview.chromium.org/2243783002
Cr-Commit-Position: refs/heads/master@{#38616}
Properly deoptimize if the left hand side of a CheckedInt32Mod is
negative and the result of the operation is zero.
R=jarin@chromium.org
BUG=v8:5286
Review-Url: https://codereview.chromium.org/2243803002
Cr-Commit-Position: refs/heads/master@{#38615}
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}
This bug was triggered by a very specific combination:
* A context-allocated variable at script scope.
* OSR optimization.
* A scheduled breakpoint, which triggers at stack checks.
Stack checks differ from other possible breakpoint locations in that
the context (among other things) may be in a register and not on the
stack, making it impossible to recover during deoptimization. The
frame_inspector then returns undefined when asked for the context.
In GetFrameDetails, handle this case by omitting all context-allocated
variables.
BUG=v8:5279
Review-Url: https://codereview.chromium.org/2245603002
Cr-Commit-Position: refs/heads/master@{#38611}
Decrease regular heap object size to 400k. In a follow up, we can now get rid of
the new space border page while keeping the 1M minimum new space size.
BUG=chromium:636331
This reverts commit 555c961990.
Review-Url: https://codereview.chromium.org/2232653003
Cr-Commit-Position: refs/heads/master@{#38608}
Reason for revert:
There is a data race in the initialization of the Isolate::random_number_generator()
Original issue's description:
> [turbofan] Split CodeGenerator::GenerateCode into AssembleCode and FinishCodeObject.
>
> This CL splits CodeGenerator::GenerateCode into two new functions:
> AssembleCode and FinishCodeObject. AssembleCode does not access or
> modify the JS heap, which means that AssembleCode can be executed on
> background threads. FinishCodeObject allocates the generated code object
> on the JS heap and therefore has to be executed on the main thread.
>
> Implementation details:
> The GenerateCode function has been split just before out-of-line code is
> assembled. The reason is that code stubs may be generated when
> out-of-line code is assembled, which potentially allocates these code
> stubs on the heap.
>
> - Parts of initialization of the CodeGenerator has been moved from the
> constructor to an Initialize function so that we can instantiate an empty
> CodeGenerator object in PipelineData.
>
> R=bmeurer@chromium.org, mstarzinger@chromium.org, titzer@chromium.org
>
> Committed: https://crrev.com/03058a2187e32cc4080612181802086527c116a2
> Cr-Commit-Position: refs/heads/master@{#38604}
TBR=bmeurer@chromium.org,mstarzinger@chromium.org,titzer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/2240523003
Cr-Commit-Position: refs/heads/master@{#38605}
This CL splits CodeGenerator::GenerateCode into two new functions:
AssembleCode and FinishCodeObject. AssembleCode does not access or
modify the JS heap, which means that AssembleCode can be executed on
background threads. FinishCodeObject allocates the generated code object
on the JS heap and therefore has to be executed on the main thread.
Implementation details:
The GenerateCode function has been split just before out-of-line code is
assembled. The reason is that code stubs may be generated when
out-of-line code is assembled, which potentially allocates these code
stubs on the heap.
- Parts of initialization of the CodeGenerator has been moved from the
constructor to an Initialize function so that we can instantiate an empty
CodeGenerator object in PipelineData.
R=bmeurer@chromium.org, mstarzinger@chromium.org, titzer@chromium.org
Review-Url: https://codereview.chromium.org/2229243003
Cr-Commit-Position: refs/heads/master@{#38604}
This adds a very first version of inlined Array.prototype.push into
TurboFan optimized code. The current inlined version has a potential
deopt loop, but it's unlikely that we hit it currently (Crankshaft
suffers from an even worse problem). Once we have a way to learn from
deopts we can fix this deopt loops.
It's also probably overly defensive in when it's safe to inline
the call to Array.prototype.push, but we can always extend that
later once we have sufficient trust in the implementation and see
an actual need to extend it.
BUG=v8:2229,v8:3952,v8:5267
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2245533003
Cr-Commit-Position: refs/heads/master@{#38603}
A TransitionElementsKind operation is redundant if we already know that
the object has the target_map (independent of what the source_map might
be).
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2233403003
Cr-Commit-Position: refs/heads/master@{#38597}
Previously, we would both instrument the code, and add/remove
BreakPointInfo objects through BreakLocation. This is bad design and
unsuitable for having two different code kinds.
We would now add/remove BreakPointInfo objects, and use that as source
of truth when instrumenting the code. If we have both bytecode and FCG
code, we would simply apply these break points twice to either.
Notable changes:
- Removed many functionality from BreakLocation.
- Instrumentation (patching code for breaks) happens by applying break
point info onto code.
- Instrumentation (code patching) is done by the BreakIterator. For
bytecode, it's BytecodeArrayBreakIterator. For FCG code, it's
CodeBreakIterator.
- Changes to code instrumentation mostly involves clearing current
instrumentation and then (re-)applying break points.
- DebugInfo can now reference both bytecode and FCG code.
R=jgruber@chromium.org, mstarzinger@chromium.org
BUG=v8:5265
Review-Url: https://codereview.chromium.org/2238893002
Cr-Commit-Position: refs/heads/master@{#38596}
port 51e9d5ad2a (r38577)
original commit message:
Use IsPropertyName in VisitObjectLiteral to decide whether to do
a named property store or call SetProperty.
BUG=
Review-Url: https://codereview.chromium.org/2241693002
Cr-Commit-Position: refs/heads/master@{#38595}
So far we only snapshot the payload data for the deserializer, but
not the data for heap reservation or the code stub keys.
At the same time this change turns some CHECKs that fail in the wild
to DCHECKs. We can try turning them back to CHECKs some other time.
TBR=ahaas@chromium.org
BUG=chromium:636876
Review-Url: https://codereview.chromium.org/2237883002
Cr-Commit-Position: refs/heads/master@{#38594}
An invocation of the ToNumber builtin resulting from lowering the
PlainPrimitiveToNumber cannot have any observable side effects and
thus the builtin call itself is eliminatable.
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2239923004
Cr-Commit-Position: refs/heads/master@{#38593}
Rolling v8/build to 37fd368b5f9d7690eac34cd440275ae323b1dab2
Rolling v8/buildtools to f8fc76ea5ce4a60cda2fa5d7df3d4a62935b3113
Rolling v8/third_party/WebKit/Source/platform/inspector_protocol to 87a50f796882982f6ae1efbd060e4f69467db547
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review-Url: https://codereview.chromium.org/2243493006
Cr-Commit-Position: refs/heads/master@{#38592}
Certain token combinations (e.g. number literal followed by semicolon) will
result in a single AST node, but require many levels of recursive descent
parsing to determine this (11 in this example). For some 'obvious'
combinations, we'll simply generate the appropriate AST node fairly far up
in the call tree.
This yields a mild but consistent parser speedup. The main con is code duplication.
[Speedup between 0..20ms in parse time among a set of 25 commonly used sites. Speedup of ~180ms for a site w/ a very large codebase (adwords.google.com). Minor slow-downs between 0..8ms for <20% of sites.]
R=marja@chromium.org
BUG=v8:4947
Review-Url: https://codereview.chromium.org/2188153002
Cr-Commit-Position: refs/heads/master@{#38591}
There's no need to check IsLexicalVariableMode since it's subsumed
by binding_needs_init.
Drive-by change: in VisitVariableLoad, move SetResultInAccumulator
out of switch cases.
BUG=
Review-Url: https://codereview.chromium.org/2232313002
Cr-Commit-Position: refs/heads/master@{#38590}
This target introduces a dependency on WebKit/platform which is not the way we want it.
Keeping the build files in src/inspector, as they are not used and will be useful later on.
BUG=none
NOPRESUBMIT=true
Review-Url: https://codereview.chromium.org/2239603002
Cr-Commit-Position: refs/heads/master@{#38587}
This optimization required access to the heap which we can't do off-thread.
There doesn't seem to be a regression without this optmization in anycase,
so just rip it out.
BUG=v8:5203
Review-Url: https://codereview.chromium.org/2238853002
Cr-Commit-Position: refs/heads/master@{#38585}
Should fix a performance regression introduced by introducing
a CanonicalHandleScope for bytecode compilation. Also fix a
missing CanonicalHandleScope in GetSharedFunctionInfo.
BUG=chromium:634953
Review-Url: https://codereview.chromium.org/2226923002
Cr-Commit-Position: refs/heads/master@{#38583}
------------------------------------------------------------------------
This CL adds support for decoding eh-related wasm opcodes:
* Throw: used for raising an exception; the thrown value lives on top of
the evaluation stack;
* TryCatch: used to start a try block that has a catch clause;
* TryFinally: used to start a try block that has a finally clause;
* TryCatchFinally: used to start a try block that has both catch and
finally clauses;
* Catch <local>: used to start the catch block of a
TryCatch/TryCatchFinally block; the thrown value is
stored in local <local>; and
* Finally: used to start a finally block of TryFinally/TryCatchFinally.
Three different opcodes are used to start a try block to simplify the
AST construction during bytecode parsing.
BUG=
Review-Url: https://codereview.chromium.org/2222193004
Cr-Commit-Position: refs/heads/master@{#38579}
This adds a very first version of inlined Array.prototype.pop into
TurboFan optimized code. We currently limit the inlining to fast
object or smi elements, until the unclear situation around hole NaNs
is resolved and we have a clear semantics inside the compiler.
It's also probably overly defensive in when it's safe to inline
the call to Array.prototype.pop, but we can always extend that
later once we have sufficient trust in the implementation and see
an actual need to extend it.
BUG=v8:2229,v8:3952,v8:5267
R=epertoso@chromium.org
Review-Url: https://codereview.chromium.org/2239703002
Cr-Commit-Position: refs/heads/master@{#38578}
Use IsPropertyName in VisitObjectLiteral to decide whether to do
a named property store or call SetProperty.
BUG=v8:5203
Review-Url: https://codereview.chromium.org/2237553004
Cr-Commit-Position: refs/heads/master@{#38577}
We can fold ConvertTaggedHoleToUndefined into CheckNumber and
CheckTaggedSigned, as they deoptimize no matter if the input
is undefined or hole.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2233393002
Cr-Commit-Position: refs/heads/master@{#38576}
