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}
Reason for revert:
Breaks g++ build.
Original issue's description:
> [turbofan] ARM: Implement vswp and use in gap resolver
>
> Use vswp to switch double-precision registers in the gap resolver, with fall
> back temp register-based code if NEON is not available.
>
> BUG=
>
> Committed: https://crrev.com/2837c2e65a2ee5b9fc610f30ce1215f52323ecbd
> Cr-Commit-Position: refs/heads/master@{#39209}
BUG=
Review-Url: https://codereview.chromium.org/2314043002
Cr-Commit-Position: refs/heads/master@{#39264}
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}
The trouble here is that the type of the induction variable might be
a bit ahead of the increment (JSAdd) operation's type. When we update
the type of the increment, we might only update the induction variable
type while the JSAdd type might be stale. If the induction variable typing
needs to fall back to normal phi typing (e.g., when the increment is not
an integer anymore), it might use the stale type.
To get around this, we fake monotonicity if we fallback to normal phi
typing. Another option would be to force re-typing of the increment
operation, but that seems to be harder to maintain.
BUG=chromium:644633
Review-Url: https://codereview.chromium.org/2320803002
Cr-Commit-Position: refs/heads/master@{#39261}
This patch fixes a bunch of out-of-date TODOs, un-skips some tests
and refers to appropriate bug numbers and current specification
status where appropriate.
R=adamk
Review-Url: https://codereview.chromium.org/2319203002
Cr-Commit-Position: refs/heads/master@{#39260}
Move it to HARMONY_STAGED bucket
Spec discussion: https://github.com/tc39/ecma402/issues/30
It's in stage 4 and Firefox has already implemented it.
BUG=v8:5244
TEST=intl/date-format/date-format-to-parts.js
TEST=test262/intl402/DateTimeFormat/prototype/formatToParts/*
Review-Url: https://codereview.chromium.org/2317783003
Cr-Commit-Position: refs/heads/master@{#39258}
While fixing the bug, removed code duplication from super load/store
runtime calls, and inlined calls of Object::ReadAbsentProperty (left
over from strong mode).
BUG=v8:5335
Review-Url: https://codereview.chromium.org/2311413002
Cr-Commit-Position: refs/heads/master@{#39257}
This yields a ~5% serialization time improvement on typical JSON-esque data.
The approach taken matches json-stringifier fairly closely.
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2311063004
Cr-Commit-Position: refs/heads/master@{#39254}
On PPC the testcase CodeSerializerLargeCodeObject fails as
the object gets allocated in the code_space section of
the heap. This is because the code_space gets expanded
successfully to 1 page size (4MB on PPC) and can accommodate
the object (size=3784608 bytes). Increasing size of the compiled
source to (5096192 bytes) so that code_space is not expanded and
the space is allocated in the Large Object space of the heap.
Testcase was added as part of https://codereview.chromium.org/2226233002R=mstarzinger@chromium.org, bmeurer@chromium.org
BUG=
LOG=N
Review-Url: https://codereview.chromium.org/2314843003
Cr-Commit-Position: refs/heads/master@{#39252}
This is analogous to the variable liveness analysis we do in the AstGraphBuilder, but on the bytecode registers.
BUG=
Review-Url: https://codereview.chromium.org/2307863002
Cr-Commit-Position: refs/heads/master@{#39248}
We were previously incorrectly changing:
sub r0, 0, r1
cmp r2, r0
b.cond <addr>
to:
cmn r2, r1
b.cond <addr>
for all conditions. This is incorrect for conditions involving the C (carry)
and V (overflow) flags, and in particular in the case where r1 = INT_MIN.
The optimization is still safe to perform for Equal and NotEqual since they
do not depend on the C and V flags.
BUG=
Review-Url: https://codereview.chromium.org/2318043002
Cr-Commit-Position: refs/heads/master@{#39246}
Migrate the isNaN, isFinite, Number.isFinite, Number.isInteger,
Number.isSafeInteger and Number.isNaN predicates to TurboFan
builtins and make them optimizable (for certain input types) in
JavaScript callees being optimized by TurboFan. That means both
the baseline and the optimized version is now always at maximum,
consistent performance. Especially TurboFan suffered from poor
baseline (and optimized) performance because it cannot play the
same weird tricks that Crankshaft plays for %_IsSmi.
This also adds a bunch of new tests to properly cover the use
of the Harmony predicates in optimized code.
R=franzih@chromium.org
BUG=v8:5049,v8:5267
Review-Url: https://codereview.chromium.org/2313073002
Cr-Commit-Position: refs/heads/master@{#39242}
Now callers of Heap::CollectGarbage* functions need to
specify the reason as an enum value instead of a string.
Subsequent CL will add stats counter for GC reason.
BUG=
Review-Url: https://codereview.chromium.org/2310143002
Cr-Commit-Position: refs/heads/master@{#39239}
In ignition, allocation site mementos were disabled when creating array
literals. Enabled them in this cl.
BUG=v8:4280
LOG=N
Review-Url: https://codereview.chromium.org/2294913006
Cr-Commit-Position: refs/heads/master@{#39234}
This moves scope-related logic (such as looking up variables) to Scope
where it belongs, and enables PreParser to do more Scope-related
operations in the future.
BUG=
Review-Url: https://codereview.chromium.org/2301183003
Cr-Commit-Position: refs/heads/master@{#39233}
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}
Spec discussion: https://github.com/tc39/ecma402/issues/30
It's in stage 4 and Firefox has already implemented it.
For now, it's added to HARMONY_IN_PROGRESS bucket behind
'--datetime-format-to-parts' flag.
BUG=v8:5244
TEST=intl/date-format/date-format-to-parts.js
TEST=test262/intl402/DateTimeFormat/prototype/formatToParts/*
Review-Url: https://codereview.chromium.org/2273953003
Cr-Commit-Position: refs/heads/master@{#39225}
Move the code to perform function name inference for properties into
parsing the properties themselves, instead of the containing object.
This allows us to avoid unnecessary calls when parsing shorthand
properties and methods and simplifies the logic in the remaining cases.
Also fixes an edge case bug: inferring the name of the getter in
`class { static get constructor(){} }`.
Review-Url: https://codereview.chromium.org/2313723005
Cr-Commit-Position: refs/heads/master@{#39222}
This extends TryToName by HeapNumber-to-intptr support and cached array
index retrieval from non-internalized strings, and uses it in the
KeyedLoadIC_Generic stub.
Bonus: avoid needless movsxlq on x64 in LoadFixed{,Double}ArrayElement
helpers by introducing INTPTR_PARAMETER mode.
Review-Url: https://codereview.chromium.org/2277363002
Cr-Commit-Position: refs/heads/master@{#39217}
For historical reasons, the interpreter's bytecode expectations tests
required a type for the constant pool. This had two disadvantages:
1. Strings and numbers were not visible in mixed pools, and
2. Mismatches of pool types (e.g. when rebaselining) would cause parser
errors
This removes the pool types, making everything 'mixed', but appending
the values to string and number valued constants. Specifying a pool type
in the *.golden header now prints a warning (for backwards compatibility).
BUG=v8:5350
Review-Url: https://codereview.chromium.org/2310103002
Cr-Commit-Position: refs/heads/master@{#39216}
This patch
- extracts the logic of keeping track of allocated bytes
from the actual incremental marking step.
- replaces OldSpaceStep with a check for incremental marking start.
- removes the force_marking parameter of AdvanceIncrementalMarking.
BUG=chromium:616434
LOG=NO
Review-Url: https://codereview.chromium.org/2304123003
Cr-Commit-Position: refs/heads/master@{#39213}
Use vswp to switch double-precision registers in the gap resolver, with fall
back temp register-based code if NEON is not available.
BUG=
Review-Url: https://codereview.chromium.org/2313803003
Cr-Commit-Position: refs/heads/master@{#39209}
This way we avoid the cyclic dependency between objects.h and heap.h and still
have one definition. Add a static assert that this size is indeed smaller than
the payload of a page.
Follow ups can finally remove the dependency on spaces.h for all heap.h users.
R=ulan@chromium.org,bmeurer@chromium.org,vogelheim@chromium.og
Review-Url: https://codereview.chromium.org/2311203002
Cr-Commit-Position: refs/heads/master@{#39206}
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}
ARMv6 has the same basic barriers as ARMv7+, but they are accessed using
the CP15 coprocessor. This patch allows the assembler to select the
appropriate instruction.
This also fixes TurboFan's atomic loads and stores for ARMv6 platforms.
BUG=
Review-Url: https://codereview.chromium.org/2318553002
Cr-Commit-Position: refs/heads/master@{#39203}
ARMv8 can use vminnm and vmaxnm to handle most inputs. Other platforms
use an implementation similar to what was there before, except that
out-of-line code is used for the uncommon cases.
BUG=
Review-Url: https://codereview.chromium.org/2313863003
Cr-Commit-Position: refs/heads/master@{#39202}
Replace first page size in the snapshots with a heap logic that trims pages
after deserialization. The snapshot provided page sizes was just an
approximation, while the heap knows exactly where to trim.
Furthermore, trim the pages directly after deserialization, leaving no wiggle
room for further objects. This avoids pollution of the immortal immovable pages
with regular objects, e.g. Contexts. The downside is that we potentially require
expanding the space with a new page.
BUG=chromium:636331
Review-Url: https://codereview.chromium.org/2311963002
Cr-Commit-Position: refs/heads/master@{#39200}
Previously we always lowered JSToBoolean(x:Number) to the subgraph
NumberLessThan(0.0, NumberAbs(x)), which deals with both 0, -0 and
NaNs appropriately. However this doesn't always generate the best,
especially when we can later derive from feedback that x is always
an Integral32 value, where the ideal code would be just a single
comparison to 0 w/o the absolute value computation.
R=mvstanton@chromium.org
BUG=v8:5267,v8:5270
Review-Url: https://codereview.chromium.org/2309953002
Cr-Commit-Position: refs/heads/master@{#39194}
These are ARMv8 instructions that will be used in a follow-up patch.
BUG=
Review-Url: https://codereview.chromium.org/2273003002
Cr-Commit-Position: refs/heads/master@{#39193}
This will allow for chaining ScopeInfos together to form the same chains
as contexts chains currently do.
BUG=v8:5215
R=mstarzinger@chromium.org,marja@chromium.org,bmeurer@chromium.org,rmcilroy@chromium.org
Review-Url: https://codereview.chromium.org/2314483002
Cr-Commit-Position: refs/heads/master@{#39192}
This restores the contract that all API methods that return Maybe<T> or
MaybeLocal<T> always throw an exception when they return nothing.
Since v8::ValueDeserializer::ReadHeader can now throw exceptions, it
needs a Local<Context> parameter so that it can set up execution state
(entering the context, etc.). The old method has been marked for
deprecation, but since this API is experimental I intend to remove it
as soon as I've removed the use from Blink.
value-serializer-unittest has been updated to expect an exception in
all decode failure cases.
BUG=chromium:148757,chromium:641964
Review-Url: https://codereview.chromium.org/2308053002
Cr-Commit-Position: refs/heads/master@{#39188}
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}
Disable the propagation of truncations through Phi, Select or TypeGuard
if the output representation is tagged, because when the truncations are
taken we don't necessarily reflect this in the types and therefore we
might end up in a situation where we produce a word32 value, the type
says Number, and now we need to change that to tagged, which is not
possible since we don't know how to interpret the bits, i.e. whether the
value is Signed32 or Unsigned32.
BUG=chromium:644048
Review-Url: https://codereview.chromium.org/2311903002
Cr-Commit-Position: refs/heads/master@{#39186}
Generate a flag-setting instruction for a binary operation when
the result is tested for equality/inequality to zero.
BUG=
Review-Url: https://codereview.chromium.org/2315453002
Cr-Commit-Position: refs/heads/master@{#39183}
