This adds a regression test for a bug where {OsrPoll} instructions
within the bytecode stream ended up outside of actual loops. This has
been fixed already, by merging {OsrPoll} into the backwards branch.
R=rmcilroy@chromium.org
TEST=mjsunit/regress/regress-crbug-645888
BUG=chromium:645888
Review-Url: https://codereview.chromium.org/2337033002
Cr-Commit-Position: refs/heads/master@{#39385}
To make better inlining decisions, it's good to have call counts for poly/mega-morphic cases. This CL makes it work for calls, and another will follow to better unify the code between constructor calls and normal calls (and thence, to record megamorphic call counts there as well).
BUG=
Review-Url: https://codereview.chromium.org/2325083003
Cr-Commit-Position: refs/heads/master@{#39377}
The raw pointer to the parameter_map might get stale in case of accessors present on
the arguments object.
Drive-by-fix: use nullptr instead of the_hole with isolate access.
BUG=chromium:645680
Review-Url: https://codereview.chromium.org/2332503002
Cr-Commit-Position: refs/heads/master@{#39359}
The whitelist is populated with those inline intrinsics that are lowered
in JSIntrinsicInlining and were not previously blacklisted. Thus the only
additional FrameStates this CL adds are those where the caller tries to
call the INLINE version of an intrinsic but ends up calling the RUNTIME
version instead.
R=bmeurer@chromium.org
BUG=chromium:644631
Review-Url: https://codereview.chromium.org/2331543002
Cr-Commit-Position: refs/heads/master@{#39357}
This fixes a corner-case where the bytecode was using the <new.target>
register directly without going through the local variable. The value
might be clobbered because the deoptimizer doesn't properly restore the
value. The label will causes bytecode pipeline to be flushed and hence
ensure {BytecodeRegisterOptimizer} doesn't reuse <new.target> anymore.
R=rmcilroy@chromium.org
TEST=mjsunit/regress/regress-crbug-645103
BUG=chromium:645103
Review-Url: https://codereview.chromium.org/2325133002
Cr-Commit-Position: refs/heads/master@{#39306}
Before this change, the spread desugaring would naively call
`%AppendElement($R, the_hole)` and in some cases $R would have
a non-holey elements kind, putting the array into the bad state
of exposing holes to author code.
This patch avoids calling %AppendElement with a hole, instead
simply incrementing $R.length when it sees a hole in the literal
(this is safe because $R is known to be an Array). The existing
logic for elements transitions takes care of giving the array a
holey ElementsKind.
BUG=chromium:644215
Review-Url: https://codereview.chromium.org/2321533003
Cr-Commit-Position: refs/heads/master@{#39294}
This adds support to the deoptimizer to materialize ContextExtension
objects that have been de-materialized by escape analysis. This is
follow-up to the inline allocation of such objects during the create
lowering phase (i.e. JSCreateWithContext and JSCreateCatchContext).
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-644245
BUG=chromium:644245
Review-Url: https://codereview.chromium.org/2317353003
Cr-Commit-Position: refs/heads/master@{#39270}
When lowering Array.prototype.push/.pop to the fast inlined version, we
first need to ensure that all prototypes (including the Object.prototype)
are stable.
R=mvstanton@chromium.org
BUG=chromium:644689
Review-Url: https://codereview.chromium.org/2319533005
Cr-Commit-Position: refs/heads/master@{#39266}
The optimization is not correct for unsigned output types, and we the
overall complexity seems too high. We need to find a better way to
take into account the input/output type restrictions.
Also added a regression test for the unsigned output bug.
BUG=v8:5267,v8:5270,v8:5357
TBR=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2320013002
Cr-Commit-Position: refs/heads/master@{#39262}
Lexically declared "arguments" in sloppy mode will throw redeclaration error
currently, this patch fixes it by delaying the declaration of arguments until we
fully parse parameter list and function body.
BUG=v8:4577
LOG=N
Committed: https://crrev.com/70a613dd0a5f5d205b46559b55702764464851fa
Review-Url: https://codereview.chromium.org/2290753003
Cr-Original-Commit-Position: refs/heads/master@{#39109}
Cr-Commit-Position: refs/heads/master@{#39230}
This adds handling of {IrOpcode::kObjectIsReceiver} nodes to the escape
status analysis. Such uses are treated as escaping for now until we add
dedicated handling to the escape analysis reducer.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-631027
BUG=chromium:631027
Review-Url: https://codereview.chromium.org/2317623003
Cr-Commit-Position: refs/heads/master@{#39205}
The constructor and new.target arguments were passed to CallConstruct in
the wrong order by BytecodeGraphBuilder, which caused subclassing to be
incorrect when optimizing from bytecode.
Also clean up some unecessary functions in interpreter.cc found while
figuring this out.
BUG=chromium:642409
Review-Url: https://codereview.chromium.org/2312103002
Cr-Commit-Position: refs/heads/master@{#39204}
This handles the case where preparation of bytecode might fail inside
Compiler::EnsureBytecode due to the underlying function being a fully
validated asm.js module. We simply bailout of bytecode preparation.
R=bradnelson@chromium.org
TEST=mjsunit/regress/regress-crbug-644111
BUG=chromium:644111
Review-Url: https://codereview.chromium.org/2309853002
Cr-Commit-Position: refs/heads/master@{#39187}
Reason for revert:
Breaks layout tests:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/9470
Original issue's description:
> Allow lexically declared "arguments" in function scope in sloppy mode.
>
> Lexically declared "arguments" in sloppy mode will throw redeclaration error
> currently, this patch fixes it by delaying the declaration of arguments until we
> fully parse parameter list and function body.
>
> BUG=v8:4577
> LOG=N
>
> Committed: https://crrev.com/70a613dd0a5f5d205b46559b55702764464851fa
> Cr-Commit-Position: refs/heads/master@{#39109}
TBR=adamk@chromium.org,mythria@chromium.org,lpy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4577
Review-Url: https://codereview.chromium.org/2304853002
Cr-Commit-Position: refs/heads/master@{#39115}
Lexically declared "arguments" in sloppy mode will throw redeclaration error
currently, this patch fixes it by delaying the declaration of arguments until we
fully parse parameter list and function body.
BUG=v8:4577
LOG=N
Review-Url: https://codereview.chromium.org/2290753003
Cr-Commit-Position: refs/heads/master@{#39109}
We use a signaling NaN to represent the hole in
FAST_HOLEY_DOUBLE_ELEMENTS backing stores, but on Intel processors, the
C++ compiler may decide to (or be forced to due to calling conventions)
use X87 registers for double values. However transfering to X87
registers automatically quietens the NaNs and there's no way to disable
this. Therefore we should just always load the hole NaN from the canonical
place identified by the address_of_hole_nan external reference instead,
which might even be more efficient in some cases.
R=jarin@chromium.org, jkummerow@chromium.org
BUG=v8:5332
Review-Url: https://codereview.chromium.org/2303643002
Cr-Commit-Position: refs/heads/master@{#39062}
When we try to further fold previously folded allocations in Crankshaft
GVN we don't properly transform the allocations involved, which causes
the mechanism to leave holes in the new/old space (and thereby violate
the iterability property of the new/old space).
BUG=chromium:621868
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2297983003
Cr-Commit-Position: refs/heads/master@{#39040}
Tail calls don't make sense from async functions and generators, as
each activation of these functions needs to make a new, distnict,
non-reused generator object. These tail calls are not required per
spec. This patch disables both syntactic and implicit tail calls
in async functions and generators.
R=neis
BUG=v8:5301,chromium:639270
Review-Url: https://codereview.chromium.org/2278413003
Cr-Commit-Position: refs/heads/master@{#38986}
This preserves the original shared code of the underlying function when
bytecode is provided. The method in question should only ensure bytecode
is present, but should avoid switching compilation tiers of the given
function. It might be that the function was fast-tracked to baseline by
inlining without going through the interpreted tier first.
R=rmcilroy@chromium.org
TEST=mjsunit/regress/regress-crbug-635923
BUG=chromium:635923
Review-Url: https://codereview.chromium.org/2278543002
Cr-Commit-Position: refs/heads/master@{#38866}
Don't bother using %_IsJSReceiver, which immediately gets lowered to
ObjectIsReceiver anyways (by the JSIntrinsicLowering), but requires
some complicated rewiring of effect/control chains.
R=mstarzinger@chromium.org
BUG=chromium:640369
Review-Url: https://codereview.chromium.org/2271973003
Cr-Commit-Position: refs/heads/master@{#38864}
Make use of %IsAsmWasmCode in place of Wasm.instantiateModuleFromAsm,
in order to reduce the surface area of the Wasm object,
and to focus on testing asm.js coming in via the parser.
Ignore extra CONST_LEGACY assignment introduced by the parser
when modules have the form:
(function Foo(a, b, c) {..});
This requires both a validator and AsmWasmBuilder change.
Move stdlib use collection to import time,
to reject modules that import a function, even if not used.
BUG= https://bugs.chromium.org/p/v8/issues/detail?id=4203
LOG=N
R=jpp@chromium.org,titzer@chromium.org
Review-Url: https://codereview.chromium.org/2264913002
Cr-Commit-Position: refs/heads/master@{#38806}
Record which asm.js stdlib members are used and add a check that NaN is actually correctly set. Other stdlib members to be added in a later change.
Also add a stdlib argument to Wasm.instantiateModuleFromAsm, in preparation for that function to be replaced by normal asm.js instantiation.
BUG= https://bugs.chromium.org/p/v8/issues/detail?id=4203
LOG=N
R=jpp@chromium.org,titzer@chromium.org
Review-Url: https://codereview.chromium.org/2251433002
Cr-Commit-Position: refs/heads/master@{#38760}
This fixes canonicalization of {SharedFunctionInfo} objects in the
{Compiler::GetSharedFunctionInfo} method when bytecode is preserved.
Eager compilation is only triggered when no code is present.
R=rmcilroy@chromium.org
TEST=mjsunit/regress/regress-crbug-638551
BUG=chromium:638551
Review-Url: https://codereview.chromium.org/2245263006
Cr-Commit-Position: refs/heads/master@{#38709}
Ensures SMI values have SMI type even if they have a dot (e.g., 1.0).
Adds SMI_WITH_DOT type to maintain this.
BUG=chromium:638134
Review-Url: https://codereview.chromium.org/2248693005
Cr-Commit-Position: refs/heads/master@{#38698}
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}
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}
For holey/growing keyed stores, we need to check that there are no
setters in the prototype chain and protect against changes to that
via code dependencies.
R=verwaest@chromium.org
BUG=v8:5275,v8:5276
Review-Url: https://codereview.chromium.org/2231683002
Cr-Commit-Position: refs/heads/master@{#38514}
When we compile a growing store in TurboFan, we don't pass a (native)
context to the %GrowArrayElements fallback function, as the whole logic
is actually context independent. However, that means that we need to
bailout early in case the object is a prototype, which requires context
dependent checks in the array protector code.
R=cbruni@chromium.org
BUG=chromium:635798
Review-Url: https://codereview.chromium.org/2224253003
Cr-Commit-Position: refs/heads/master@{#38491}
This fixes the runtime profiler to no longer assume that seeing an
optimized frame on the stack implies the underlying function is not
being interpreted when entered normally. This no longer holds with code
generated for OSR directly from bytecode (not installed on function).
R=rmcilroy@chromium.org
TEST=mjsunit/regress/regress-crbug-632800
BUG=chromium:632800
Review-Url: https://codereview.chromium.org/2208603005
Cr-Commit-Position: refs/heads/master@{#38360}
This makes sure we prevent a tier-up for function which also have an
optimized activation of OSR code on the stack. In case the OSR code
deoptimizes, it needs the bytecode to still be around.
R=rmcilroy@chromium.org
TEST=mjsunit/regress/regress-5262
BUG=v8:5262
Review-Url: https://codereview.chromium.org/2206363004
Cr-Commit-Position: refs/heads/master@{#38359}
We don't need to add stability dependencies on JSObject prototypes when
storing to an element, because we do the map check (and thereby guard
the elements kind) and we also properly deoptimize on holes if the array
protector is not usable.
R=verwaest@chromium.org
BUG=chromium:616709
Review-Url: https://codereview.chromium.org/2198833002
Cr-Commit-Position: refs/heads/master@{#38355}
This adds the missing lazy bailout point when defining accessor pairs
within object literals via Runtime::kDefineAccessorPropertyUnchecked.
The runtime function in question can indeed trigger a lazy deopt due
to a DependentCode::kPrototypeCheckGroup dependency.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-633585
BUG=chromium:633585
Review-Url: https://codereview.chromium.org/2207413002
Cr-Commit-Position: refs/heads/master@{#38336}
An infinite recursion can be triggered when NoSideEffectToString is
called on an error object with its name property set to itself.
BUG=633998
Review-Url: https://codereview.chromium.org/2206313002
Cr-Commit-Position: refs/heads/master@{#38325}
Avoids compiling baseline code when the function isn't able to be
optimized by crankshaft.
BUG=chromium:632289
Review-Url: https://codereview.chromium.org/2194453002
Cr-Commit-Position: refs/heads/master@{#38304}
We cannot just blindly make a representation selection for Phi or Select
based on the truncations, but we also need to consider the type of the
inputs (or actually of the Phi/Select node itself). We can only use
Word32 representation based on Word32 truncation if the inputs are
Number or Oddball, same for Float64.
R=epertoso@chromium.org
BUG=v8:5255
Review-Url: https://codereview.chromium.org/2206553002
Cr-Commit-Position: refs/heads/master@{#38241}
This makes sure we are not inserting {OsrPoll} instructions for any
statements that are not actually loops and have no back edges. Without
back edges the {BytecodeGraphBuilder} is unable to deduce loop ranges
and hence cannot construct a graph for OSR entry.
R=neis@chromium.org
TEST=mjsunit/regress/regress-5252
BUG=v8:5252
Review-Url: https://codereview.chromium.org/2200733002
Cr-Commit-Position: refs/heads/master@{#38233}
When we narrow a signed32 comparison to uint8 or uint16 representation,
we also need to change the condition to unsigned comparisons otherwise
the comparison will be done on int16/int8 which interprets the narrowed
bits wrong.
R=epertoso@chromium.org
BUG=v8:5254
Review-Url: https://codereview.chromium.org/2202803003
Cr-Commit-Position: refs/heads/master@{#38231}
Previously, the stack property was set up in JS as read-only; but since
it had a JS setter, writability was ignored and writing to stack was
possible.
This is no longer the case now that stack is either an actual data
property, or is associated with C++ accessors. Explicitly set the
property as writable to preserve old behavior.
BUG=5245
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2190313002
Cr-Commit-Position: refs/heads/master@{#38158}
