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}
Reason for revert:
Revert to check if this is causing perf regressions in crbug.com/645411
Original issue's description:
> [heap] Fix a formatting bug in --trace-incremental-marking.
>
> BUG=
>
> Committed: https://crrev.com/212624b7570cd1c1cfad7cf958203b05af961637
> Cr-Commit-Position: refs/heads/master@{#39278}
TBR=mlippautz@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review-Url: https://codereview.chromium.org/2323293002
Cr-Commit-Position: refs/heads/master@{#39305}
For call sites where the target is not a known constant, but potentially
a list of known constants (i.e. a Phi with all HeapConstant inputs), we
still record the call site as a potential candidate for inlining.
In case the heuristic picks that candidate for inlining, we
expand the call site to a dispatched call site and invoke the
actual inlining logic for all the nested call sites.
Like Crankshaft, we currently allow up to 4 targets for polymorphic inlining,
although we might want to refine that later.
This approach is different from what Crankshaft does in
that we don't duplicate the evaluation of the parameters per polymorphic
case. Instead we first perform the load of the target (which usually
dispatches based on the receiver map), then we evaluate all the
parameters, and then we dispatch again based on the known targets. This
might generate better or worse code compared to what Crankshaft does,
and for the cases where we generate worse code (i.e. because we have
only trivial parameters or no parameters at all), we might want to
investigate optimizing away the double dispatch in the
future.
R=mvstanton@chromium.org
BUG=v8:5267,v8:5365
Review-Url: https://codereview.chromium.org/2325943002
Cr-Commit-Position: refs/heads/master@{#39302}
This is a work-around as v8_enable_i18n_support=false does
currently not imply icu_use_data_file_flag=false. The
swarming isolator then tries to find the data file also
in builds without ICU.
Making the implication is non-trivial as icu_use_data_file_flag lives
in ICU and v8_enable_i18n_support lives in V8.
BUG=chromium:474921
NOTRY=true
TBR=petermarshall@chromium.org, vogelheim@chromium.org, jochen@chromium.org
Review-Url: https://codereview.chromium.org/2321563007
Cr-Commit-Position: refs/heads/master@{#39301}
port 9a31162d9d3137d09063d6040865655b2e386384(r39283)
original commit message:
Adds support to collect allocation site feedback for Array function calls
to the call bytecode handler.
BUG=
Review-Url: https://codereview.chromium.org/2319123004
Cr-Commit-Position: refs/heads/master@{#39299}
Without this cast, the integer type isn't promoted before being shifted, and so
for types larger than sizeof(int) there is data loss. This will become an issue
once the host begins using this helper to send 64-bit integers.
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2326653002
Cr-Commit-Position: refs/heads/master@{#39296}
This patch adds runtime call stats tracing for GC correctly, makes
--runtime-call-stats and tracing mutually exclusive with tracing taking
precedence if both modes are on, and uses only one runtime call stats in
counter.
BUG=v8:5089
Review-Url: https://codereview.chromium.org/2313193002
Cr-Commit-Position: refs/heads/master@{#39295}
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 CL fixes %DebugPrint for FAST_HOLEY_DOUBLE_ELEMENTS and now properly
distinguishes TheHole and NaN values.
BUG=
Review-Url: https://codereview.chromium.org/2294913004
Cr-Commit-Position: refs/heads/master@{#39293}
Reason for revert:
There have been no more occurrences of this on dev / beta so we can convert the CHECK back to DCHECK.
Original issue's description:
> [runtime] temporarily transform IsContext check from DCHECK to CHECK
>
> We are enabling this trial on canary to see if we can flush out some missing
> context restores.
>
> BUG=
>
> Committed: https://crrev.com/ec94ad400dc257af396efa3b1899bc3168347d82
> Cr-Commit-Position: refs/heads/master@{#37875}
TBR=jkummerow@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=
Review-Url: https://codereview.chromium.org/2303543003
Cr-Commit-Position: refs/heads/master@{#39292}
The previous DCHECK (removed in issue 2316033002) was checking that the new interval strictly overlapped with the first interval.
BUG=
Review-Url: https://codereview.chromium.org/2321113002
Cr-Commit-Position: refs/heads/master@{#39290}
Fell through the cracks in a recent CL. Should have switched
with the CI bot, which is on GN already.
BUG=chromium:474921
NOTRY=true
Review-Url: https://codereview.chromium.org/2328533002
Cr-Commit-Position: refs/heads/master@{#39285}
Adds support to collect allocation site feedback for Array function calls
to the call bytecode handler.
BUG=v8:4280, v8:4780
LOG=N
Review-Url: https://codereview.chromium.org/2307903002
Cr-Commit-Position: refs/heads/master@{#39283}
The existing PropertyQueryCallback intercepts getOwnPropertyDescriptor, but
it returns only value and attributes, not the accessors. This
PropertyDescriptorCallback returns a descriptor similar to Ecma-262 6.2.4.
You can either set a PropertyQueryCallback or a PropertyDescriptorCallback,
but not both. When you set a callback for DefineProperty(), you can set a
PropertyDescriptorCallback but not a PropertyQueryCallback.
BUG=v8:5359
Review-Url: https://codereview.chromium.org/2311873002
Cr-Commit-Position: refs/heads/master@{#39279}
This fixes the materialization of JSFunction objects to not rely on a
context being available. The context has been cleared because it might
be de-materiallized itself.
R=bmeurer@chromium.org
TEST=mjsunit/compiler/escape-analysis-materialize
BUG=chromium:644245
Review-Url: https://codereview.chromium.org/2320983002
Cr-Commit-Position: refs/heads/master@{#39277}
The test was using some callee saved registers but tests don't save those.
BUG=v8:5354
Review-Url: https://codereview.chromium.org/2322923002
Cr-Commit-Position: refs/heads/master@{#39275}
This fixes the materialization of JSArray objects to not rely on a
context being available. The context has been cleared because it might
be de-materiallized itself.
R=bmeurer@chromium.org
BUG=chromium:644245
Review-Url: https://codereview.chromium.org/2323713002
Cr-Commit-Position: refs/heads/master@{#39274}
This patch moves the following parsing methods to ParserBase:
- ParseScopedStatement
- ParseVariableStatement
- ParseDebuggerStatement
- ParseV8Intrinsic
It also cleans up the implementation-specific use counter mechanism.
R=adamk@chromium.org, marja@chromium.org
BUG=
LOG=N
Review-Url: https://codereview.chromium.org/2318263002
Cr-Commit-Position: refs/heads/master@{#39272}
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}
Also roll build and android_tools, which contains a bump of
the ndk to r12b.
BUG=chromium:629806
Review-Url: https://codereview.chromium.org/2320843003
Cr-Commit-Position: refs/heads/master@{#39269}
Delete unused CSA::AllocateUninitializedFixedArray() which also does not
respect ParameterMode concept.
Review-Url: https://codereview.chromium.org/2321643002
Cr-Commit-Position: refs/heads/master@{#39268}
This clears the context register by setting it to Smi(0) before calling
the Runtime::kNotifyDeoptimized helper. The deoptimizer must be able to
materialize all heap objects without any context available. The context
itself might be dematerialized.
With this change we make sure that invariant is maintained even without
escape analysis kicking in. We also satisfy the check that the context
register is either Smi(0) or a valid context. It might have been the
special {arguments_marker} in this particular case.
R=bmeurer@chromium.org
BUG=chromium:644245
Review-Url: https://codereview.chromium.org/2320673002
Cr-Commit-Position: refs/heads/master@{#39267}
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}
