Commit Graph

974 Commits

Author SHA1 Message Date
mstarzinger
3fc0224cfc [compiler] Add baseline tier to compilation pipeline.
This adds a baseline tier to the compilation pipeline. Currently this
tier is used to model a path from the interpreter to optimized code via
full-codegen code (to ensure sufficient type feedback). Switching from
the unoptimized tier to the baseline tier is limited to happen only when
there are no activations of the given function on the stack.

R=rmcilroy@chromium.org,bmeurer@chromium.org

Review URL: https://codereview.chromium.org/1903273004

Cr-Commit-Position: refs/heads/master@{#35757}
2016-04-25 10:48:34 +00:00
mstarzinger
6f43e1f544 [profiler] Remove obsolete CompilationInfo argument.
This removes the CompilationInfo argument from one of the logging
functions where it is unused. The long-term goal is to not pass around
the CompilationInfo at all. The assumption that the CompilationInfo is
available is incompatible with serialized code, where compilation has
happened during building time of V8 itself.

R=yangguo@chromium.org

Review URL: https://codereview.chromium.org/1901353003

Cr-Commit-Position: refs/heads/master@{#35705}
2016-04-21 13:18:27 +00:00
mstarzinger
c323d2a64e [compiler] Remove obsolete check for debug break slots.
This check whether a function is being debugged is obsolete. For the
optimization path it is covered by a bailout further down. The lookup
within the optimized code map doesn't need to be covered, because that
map is guaranteed to stay empty while break slots are present.

R=mvstanton@chromium.org

Review URL: https://codereview.chromium.org/1907923003

Cr-Commit-Position: refs/heads/master@{#35694}
2016-04-21 10:15:15 +00:00
mstarzinger
2e9920afd0 [compiler] Rename "baseline" to "unoptimized" in pipeline.
This is just a pure renaming because "baseline" will be the code name
for our upcoming middle tier within the compilation pipeline. It makes
sure the name "baseline" remains unused.

R=rmcilroy@chromium.org

Review URL: https://codereview.chromium.org/1904463002

Cr-Commit-Position: refs/heads/master@{#35661}
2016-04-20 14:13:25 +00:00
mstarzinger
59d08247c7 [compiler] Remove CompilationInfo::abstract_code accessor.
In the long run we do not want to rely on compilation results being
available on the CompilationInfo. This removes the accessor for the
abstract code, which is very inviting to be used outside of compilation
pipeline.

R=yangguo@chromium.org

Review URL: https://codereview.chromium.org/1903723002

Cr-Commit-Position: refs/heads/master@{#35653}
2016-04-20 11:07:41 +00:00
mstarzinger
85870e8698 [compiler] Extract scope info installation into helper.
This moves the installation of the scope info object on the shared
function info into a separate helper to share common code. This is
preparatory work in order to reuse existing scope info objects.

R=bmeurer@chromium.org

Review URL: https://codereview.chromium.org/1894023004

Cr-Commit-Position: refs/heads/master@{#35647}
2016-04-20 08:52:21 +00:00
mstarzinger
45ad04fdd2 [compiler] Remove remnants from concurrent OSR.
This removes some obsolete conditions checking whether we are performing
concurrent OSR compilation. This feature has been removed some time ago.

R=yangguo@chromium.org

Review URL: https://codereview.chromium.org/1901163003

Cr-Commit-Position: refs/heads/master@{#35646}
2016-04-20 08:49:58 +00:00
yangguo
91e2bf6e37 Make global eval faster by lazily computing its call position.
Prior to 89d7bfda we always just collected the code offset and computed the
source position lazily. However, for local eval we already have the source
position ready, so we can just store that. For global eval we still have to
compute from the code offset. This CL changes the computation to be done only
on demand.

R=mstarzinger@chromium.org
BUG=chromium:604646
LOG=N

Review URL: https://codereview.chromium.org/1903463002

Cr-Commit-Position: refs/heads/master@{#35630}
2016-04-19 16:18:09 +00:00
mstarzinger
08ef00fd06 [compiler] Reuse parse info when ensuring deopt support.
R=titzer@chromium.org

Review URL: https://codereview.chromium.org/1901653003

Cr-Commit-Position: refs/heads/master@{#35612}
2016-04-19 11:20:43 +00:00
mstarzinger
d784c2d1ea [compiler] Remove remnants for old-skool live edit.
This removes obsolete code that supports compiling without a shared
function info object. Even for top-level code compiled for live edit
such an object is allocated by now.

R=yangguo@chromium.org

Review URL: https://codereview.chromium.org/1896083002

Cr-Commit-Position: refs/heads/master@{#35609}
2016-04-19 09:33:08 +00:00
mstarzinger
1041340220 [compiler] Let CompileForLiveEdit use common pipeline.
This makes sure that the Compiler::CompileForLiveEdit API function uses
the common pipeline for top-level code. It ensures that a proper shared
function info object is allocated before compilation is triggered.

R=yangguo@chromium.org

Review URL: https://codereview.chromium.org/1900613002

Cr-Commit-Position: refs/heads/master@{#35590}
2016-04-18 16:17:26 +00:00
neis
d0ccddd032 First version of the new generators implementation.
Behind --ignition-generators. Does not yet support Turbofan.

TBR=bmeurer@chromium.org
BUG=v8:4907
LOG=n

Review URL: https://codereview.chromium.org/1884183002

Cr-Commit-Position: refs/heads/master@{#35584}
2016-04-18 14:13:30 +00:00
mstarzinger
e9dfcf4f0c [compiler] Introduce common structure to compile methods.
This should be a plain refactoring change with only negligible changes
to method semantics. The main aim is to improve readability of some API
method implementations.

R=mvstanton@chromium.org

Review URL: https://codereview.chromium.org/1895033003

Cr-Commit-Position: refs/heads/master@{#35583}
2016-04-18 14:13:29 +00:00
yangguo
89d7bfda0d Correctly annotate eval origin.
There were a couple of issues with it:
- interpreter is not supported
- the source position was just accidentally correct for full-codegen
- the eval origin could have been cached

Also fixes a few other places to use AbstractCode.

R=mstarzinger@chromium.org

Committed: https://crrev.com/2f3a171adc9e620c2235bf0562145b9d4eaba66d
Cr-Commit-Position: refs/heads/master@{#35257}

Committed: https://crrev.com/ad4e8a27963b704bb70ec8bac0991c57296b1d16
Cr-Commit-Position: refs/heads/master@{#35481}

Review URL: https://codereview.chromium.org/1854713002

Cr-Commit-Position: refs/heads/master@{#35581}
2016-04-18 13:21:07 +00:00
mstarzinger
31e4644682 [compiler] Remove obsolete CompileUnoptimizedCode helper.
This removes the helper function in question that side-steps the
interpreter without going through the canonical UseIgnition predicate.
Having such a function is dangerous as it hides paths that are not yet
covered by the interpreter (like live edit in this case).

R=yangguo@chromium.org

Review URL: https://codereview.chromium.org/1895763002

Cr-Commit-Position: refs/heads/master@{#35580}
2016-04-18 13:07:29 +00:00
mstarzinger
e2ff7d121d [compiler] Simplify Compiler::CompileDebugCode a bit.
R=yangguo@chromium.org

Review URL: https://codereview.chromium.org/1897793002

Cr-Commit-Position: refs/heads/master@{#35579}
2016-04-18 12:59:26 +00:00
mstarzinger
8a29223c01 [compiler] Prevent unnecessary parsing with interpreter.
This disables parsing when we optimize directly from bytecode using
TurboFan, because TurboFan is capable of building graphs out of the
bytecode directly.

R=bmeurer@chromium.org
BUG=v8:4280
LOG=n

Review URL: https://codereview.chromium.org/1891663004

Cr-Commit-Position: refs/heads/master@{#35567}
2016-04-18 09:11:16 +00:00
jochen
0b638f0a85 Produce a code cache if the embedder asks for one
Even if there's already one in memory

BUG=
R=yangguo@chromium.org

Review URL: https://codereview.chromium.org/1900483002

Cr-Commit-Position: refs/heads/master@{#35564}
2016-04-18 08:13:57 +00:00
mstarzinger
1c81ad3f66 [compiler] Hoist bailouts out of OptimizedCompileJob.
This hoists all bailouts out of OptimizedCompileJob::CreateGraph into
the compiler pipeline. The reason is that this moves them to a point
where we can still influence the decision which compiler to pick and
hence gives us more freedom with modeling various pipelines.

R=neis@chromium.org

Review URL: https://codereview.chromium.org/1883313003

Cr-Commit-Position: refs/heads/master@{#35532}
2016-04-15 13:42:07 +00:00
mstarzinger
62cca39e6c [compiler] Move ensuring deoptimization support to backends.
This moves the responsibility of preparing full-codegen code with
deoptimization support into the backends. This avoids generating such
code when optimization can be done directly from existing bytecode.

R=bmeurer@chromium.org
BUG=v8:4280
LOG=n

Review URL: https://codereview.chromium.org/1883403002

Cr-Commit-Position: refs/heads/master@{#35517}
2016-04-15 11:26:44 +00:00
mstarzinger
139617b0d5 [compiler] Drop obsolete bailout for builtin context.
The builtin context is not a thing anymore. This means we don't have to
worry about being able to deserialize it when optimizing top-level code.

R=bmeurer@chromium.org

Review URL: https://codereview.chromium.org/1891793002

Cr-Commit-Position: refs/heads/master@{#35502}
2016-04-14 18:49:52 +00:00
yangguo
5af0a68442 Revert of Correctly annotate eval origin. (patchset #5 id:80001 of https://codereview.chromium.org/1854713002/ )
Reason for revert:
performance impact

Original issue's description:
> Correctly annotate eval origin.
>
> There were a couple of issues with it:
> - interpreter is not supported
> - the source position was just accidentally correct for full-codegen
> - the eval origin could have been cached
>
> Also fixes a few other places to use AbstractCode.
>
> R=mstarzinger@chromium.org
>
> Committed: https://crrev.com/2f3a171adc9e620c2235bf0562145b9d4eaba66d
> Cr-Commit-Position: refs/heads/master@{#35257}
>
> Committed: https://crrev.com/ad4e8a27963b704bb70ec8bac0991c57296b1d16
> Cr-Commit-Position: refs/heads/master@{#35481}

TBR=mstarzinger@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/1888013002

Cr-Commit-Position: refs/heads/master@{#35491}
2016-04-14 12:46:00 +00:00
mstarzinger
b62af118f4 [compiler] Remove obsolete MaybeDisableOptimization.
The parser no longer disables optimization. This is done solely by the
renumbering stage. It is sufficient to mark a SharedFunctionInfo as
disabled for optimization right after the renumbering stage.

R=bmeurer@chromium.org

Review URL: https://codereview.chromium.org/1891753002

Cr-Commit-Position: refs/heads/master@{#35490}
2016-04-14 12:32:19 +00:00
mstarzinger
b958ba5fd8 [compiler] Remove CompilationInfo::is_first_compile flag.
This removes the flag in question. It just duplicates the corresponding
compilation hint in the underlying SharedFunctionInfo object. Now that
the backends should have a SharedFunctionInfo available most of the time
it is safe to use the cannonical predicate.

R=bmeurer@chromium.org

Review URL: https://codereview.chromium.org/1883583002

Cr-Commit-Position: refs/heads/master@{#35482}
2016-04-14 10:28:02 +00:00
yangguo
ad4e8a2796 Correctly annotate eval origin.
There were a couple of issues with it:
- interpreter is not supported
- the source position was just accidentally correct for full-codegen
- the eval origin could have been cached

Also fixes a few other places to use AbstractCode.

R=mstarzinger@chromium.org

Committed: https://crrev.com/2f3a171adc9e620c2235bf0562145b9d4eaba66d
Cr-Commit-Position: refs/heads/master@{#35257}

Review URL: https://codereview.chromium.org/1854713002

Cr-Commit-Position: refs/heads/master@{#35481}
2016-04-14 10:08:15 +00:00
mstarzinger
35395d988e [compiler] Fix optimized code lookup in GetLazyCode.
This makes sure that when cached optimized code is found while doing
lazy compilation via Compiler::Compile installs any existing literals
array as well.

R=mvstanton@chromium.org

Review URL: https://codereview.chromium.org/1879973005

Cr-Commit-Position: refs/heads/master@{#35477}
2016-04-14 09:20:39 +00:00
mstarzinger
3699f902d6 [compiler] Remove CompileEvalForDebugging pipeline.
This removes one of the duplicated pipeline implementation from the
compiler. By now we can reuse the existing CompileForDebugging for all
compilations being kicked off for debugging.

R=bmeurer@chromium.org

Review URL: https://codereview.chromium.org/1885063002

Cr-Commit-Position: refs/heads/master@{#35472}
2016-04-14 08:08:43 +00:00
mstarzinger
793ae860e5 [compiler] Drop obsolete compiler hint setting.
The compiler hints in question are already correctly initialized by the
NewSharedFunctionInfoForLiteral function. Reinitializing them again here
is no longer needed by now.

R=bmeurer@chromium.org

Review URL: https://codereview.chromium.org/1887673002

Cr-Commit-Position: refs/heads/master@{#35471}
2016-04-14 08:01:06 +00:00
mvstanton
c2de961128 RESUBMITTING: Bogus assert prevented chromium roll.
Visit the Optimized Code Map on first call rather than closure creation.

This is useful for escape analysis, and helps upcoming changes to
type feedback gathering.

Adding notry due to crashed builders:
NOTRY=true
BUG=

Committed: https://crrev.com/9336f4cc6d25d39a128176679a70dbd13a6d946e
Cr-Commit-Position: refs/heads/master@{#35395}

Review URL: https://codereview.chromium.org/1670143002

Cr-Commit-Position: refs/heads/master@{#35440}
2016-04-13 10:55:39 +00:00
hablich
f021b7ca8f Revert of Visit the Optimized Code Map on first call rather than closure creation. (patchset #7 id:120001 of https://codereview.chromium.org/1670143002/ )
Reason for revert:
Blocks roll. See https://codereview.chromium.org/1877003002/ for detailed messages.

You should be able to repro this with Linux ASAN.

Original issue's description:
> Visit the Optimized Code Map on first call rather than closure creation.
>
> This is useful for escape analysis, and helps upcoming changes to
> type feedback gathering.
>
> BUG=
>
> Committed: https://crrev.com/9336f4cc6d25d39a128176679a70dbd13a6d946e
> Cr-Commit-Position: refs/heads/master@{#35395}

TBR=mstarzinger@chromium.org,bmeurer@chromium.org,mvstanton@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/1878063004

Cr-Commit-Position: refs/heads/master@{#35404}
2016-04-12 07:59:11 +00:00
hablich
b88d048adf Reland of [compiler] Make feedback vector cope with flag changes. (patchset #1 id:1 of https://codereview.chromium.org/1876103002/ )
Reason for revert:
Did not fail on another roll including this CL ..

Original issue's description:
> Revert of [compiler] Make feedback vector cope with flag changes. (patchset #1 id:1 of https://codereview.chromium.org/1869693003/ )
>
> Reason for revert:
> Blocks current roll: https://codereview.chromium.org/1876713002/ according to bisect: https://codereview.chromium.org/1872353002/#ps80001
>
> Original issue's description:
> > [compiler] Make feedback vector cope with flag changes.
> >
> > This fixes corner cases where the layout of feedback vectors baked into
> > the snapshot is different from the expected layout, depending on some
> > runtime flags. We make sure the feedback vector is regenereated for
> > functions that are not compiled. Flag changes of this kind are only
> > allowed when code is not serialized.
> >
> > An alternative solution would be to not serialize the feedback vector
> > for such cases in the first place. That solution however would have a
> > higher overhead, as it would required the serializer to be able to
> > recognize feedback vectors while generating a snapshot.
> >
> > R=mvstanton@chromium.org
> > TEST=mjsunit/regress/regress-crbug-600995
> > BUG=chromium:600995
> > LOG=n
> >
> > Committed: https://crrev.com/460bff5fb6af2bd79e610f89afdf6da9dba3cf0c
> > Cr-Commit-Position: refs/heads/master@{#35339}
>
> TBR=mvstanton@chromium.org,mstarzinger@chromium.org
>
> BUG=chromium:600995
> LOG=N
> NOTRY=true
>
> Committed: https://crrev.com/78049e9c4837f053575d6c71e53ae12fec99f1aa
> Cr-Commit-Position: refs/heads/master@{#35392}

TBR=mvstanton@chromium.org,mstarzinger@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:600995

Review URL: https://codereview.chromium.org/1876973002

Cr-Commit-Position: refs/heads/master@{#35398}
2016-04-11 18:56:37 +00:00
mvstanton
9336f4cc6d Visit the Optimized Code Map on first call rather than closure creation.
This is useful for escape analysis, and helps upcoming changes to
type feedback gathering.

BUG=

Review URL: https://codereview.chromium.org/1670143002

Cr-Commit-Position: refs/heads/master@{#35395}
2016-04-11 17:28:20 +00:00
hablich
78049e9c48 Revert of [compiler] Make feedback vector cope with flag changes. (patchset #1 id:1 of https://codereview.chromium.org/1869693003/ )
Reason for revert:
Blocks current roll: https://codereview.chromium.org/1876713002/ according to bisect: https://codereview.chromium.org/1872353002/#ps80001

Original issue's description:
> [compiler] Make feedback vector cope with flag changes.
>
> This fixes corner cases where the layout of feedback vectors baked into
> the snapshot is different from the expected layout, depending on some
> runtime flags. We make sure the feedback vector is regenereated for
> functions that are not compiled. Flag changes of this kind are only
> allowed when code is not serialized.
>
> An alternative solution would be to not serialize the feedback vector
> for such cases in the first place. That solution however would have a
> higher overhead, as it would required the serializer to be able to
> recognize feedback vectors while generating a snapshot.
>
> R=mvstanton@chromium.org
> TEST=mjsunit/regress/regress-crbug-600995
> BUG=chromium:600995
> LOG=n
>
> Committed: https://crrev.com/460bff5fb6af2bd79e610f89afdf6da9dba3cf0c
> Cr-Commit-Position: refs/heads/master@{#35339}

TBR=mvstanton@chromium.org,mstarzinger@chromium.org

BUG=chromium:600995
LOG=N
NOTRY=true

Review URL: https://codereview.chromium.org/1876103002

Cr-Commit-Position: refs/heads/master@{#35392}
2016-04-11 15:36:30 +00:00
mstarzinger
8ce0a943e3 [compiler] Set expect property count right after parsing.
This moves the computation of the {expected_nof_properties} for a shared
function to where the object is actually being allocated. This is done
after parsing when the literal has been populated already. The expected
number of properties is not mutated after parsing.

R=verwaest@chromium.org

Review URL: https://codereview.chromium.org/1873173002

Cr-Commit-Position: refs/heads/master@{#35391}
2016-04-11 14:54:32 +00:00
mstarzinger
e37e6fc766 [compiler] Make --hydrogen-filter only apply to Crankshaft.
This makes sure that --hydrogen-filter only filters for Crankshaft, not
for TurboFan compilations. For TurboFan there is --turbo-filter as a
separate flag already. There no longer is a single flag to filter both
compilers at the same time, one can still specify both flags however.

R=jkummerow@chromium.org

Review URL: https://codereview.chromium.org/1871343003

Cr-Commit-Position: refs/heads/master@{#35388}
2016-04-11 13:54:51 +00:00
bmeurer
086bc49894 [turbofan] Remove support for --turbo-types.
We had exactly one test case for --noturbo-types, so it's likely that
the generic pipeline (without types) was already broken for quite some
time, plus no one expressed interest in maintaining it, plus it
complicates the JSGenericLowering integration. So decision is to kill
it.

R=jarin@chromium.org

Review URL: https://codereview.chromium.org/1872333002

Cr-Commit-Position: refs/heads/master@{#35387}
2016-04-11 12:57:28 +00:00
mstarzinger
318cc682f4 [compiler] Move tracing from backends to compiler.
R=bmeurer@chromium.org

Review URL: https://codereview.chromium.org/1872833002

Cr-Commit-Position: refs/heads/master@{#35384}
2016-04-11 12:07:46 +00:00
mstarzinger
dea67cf0e3 [compiler] Make OptimizedCompileJob agnostic from backend.
This refactors the OptimizedCompileJob class to be agnostic from the
actual underlying compiler. Instead it represents a base class for all
compilation jobs. The implementation is provided by the backend by just
overriding the phase methods.

Also note that this contains the semantics change of not falling back to
Crankshaft when TurboFan optimization fails. This fallback is no longer
needed and will not be supported going forward.

R=bmeurer@chromium.org

Review URL: https://codereview.chromium.org/1872483002

Cr-Commit-Position: refs/heads/master@{#35377}
2016-04-11 10:02:26 +00:00
mstarzinger
1407c89427 [parser] Remove ParseInfo::closure field.
The parser should never need to look at the underlying closure object,
hence the field can be moved from ParseInfo into CompilationInfo.

R=rossberg@chromium.org

Review URL: https://codereview.chromium.org/1863083002

Cr-Commit-Position: refs/heads/master@{#35358}
2016-04-08 12:32:23 +00:00
mstarzinger
03c169f957 [compiler] Deprecate CompilationInfo::has_context predicate.
R=bmeurer@chromium.org

Review URL: https://codereview.chromium.org/1863793004

Cr-Commit-Position: refs/heads/master@{#35348}
2016-04-08 08:30:30 +00:00
mstarzinger
460bff5fb6 [compiler] Make feedback vector cope with flag changes.
This fixes corner cases where the layout of feedback vectors baked into
the snapshot is different from the expected layout, depending on some
runtime flags. We make sure the feedback vector is regenereated for
functions that are not compiled. Flag changes of this kind are only
allowed when code is not serialized.

An alternative solution would be to not serialize the feedback vector
for such cases in the first place. That solution however would have a
higher overhead, as it would required the serializer to be able to
recognize feedback vectors while generating a snapshot.

R=mvstanton@chromium.org
TEST=mjsunit/regress/regress-crbug-600995
BUG=chromium:600995
LOG=n

Review URL: https://codereview.chromium.org/1869693003

Cr-Commit-Position: refs/heads/master@{#35339}
2016-04-07 15:35:03 +00:00
mstarzinger
105777a036 [turbofan] Deprecate CompilationInfo::has_scope predicate.
Now that we no longer compile stubs from JavaScript source, but have
other means of generating stubs using our optimizing compilers, we can
assume that scope analysis has happened whenever prologues are being
assembled.

R=bmeurer@chromium.org

Review URL: https://codereview.chromium.org/1863333004

Cr-Commit-Position: refs/heads/master@{#35329}
2016-04-07 09:54:13 +00:00
mstarzinger
51d3932580 [turbofan] Deprecate CompilationInfo::has_literal predicate.
Now that the SharedFunctionInfo is available to compilers all of the
time, we no longer need to rely on the literal for source printing.

R=titzer@chromium.org

Review URL: https://codereview.chromium.org/1866613003

Cr-Commit-Position: refs/heads/master@{#35326}
2016-04-07 08:44:45 +00:00
mstarzinger
099189f400 [compiler] Simplify GetLazyCode for asm functions.
R=bmeurer@chromium.org

Review URL: https://codereview.chromium.org/1868553003

Cr-Commit-Position: refs/heads/master@{#35323}
2016-04-07 08:21:49 +00:00
mstarzinger
55515c998a [compiler] Remove obsolete GetUnoptimizedCodeCommon.
This removes an unnecessary abstraction from the implementation of the
compilation pipeline that is no longer needed by now.

R=bmeurer@chromium.org

Review URL: https://codereview.chromium.org/1868553002

Cr-Commit-Position: refs/heads/master@{#35313}
2016-04-06 19:20:51 +00:00
mstarzinger
56c7d4b4f9 [compiler] Remove CompilationInfo::opt_count field.
This field duplicates information from the SharedFunctionInfo. Now that
backends are guaranteed to have a SharedFunctionInfo around, we drop it.

R=verwaest@chromium.org

Review URL: https://codereview.chromium.org/1860123003

Cr-Commit-Position: refs/heads/master@{#35312}
2016-04-06 19:16:57 +00:00
bmeurer
974721c661 [generators] Decouple generator resume from fullcodegen.
Introduce a ResumeGeneratorTrampoline, which does the actual stack state
reconstruction (currently always restores a fullcodegen frame), and
introduce appropriate TurboFan builtins for %GeneratorPrototype%.next,
%GeneratorPrototype%.return and %GeneratorPrototype%.throw based on
this native builtin.

Also unify the flooding in case of step-in to always work based on
JSFunction and remove the special casing for JSGeneratorObject.

R=mstarzinger@chromium.org, neis@chromium.org
TBR=rossberg@chromium.org
BUG=chromium:513471
LOG=n

Review URL: https://codereview.chromium.org/1865833002

Cr-Commit-Position: refs/heads/master@{#35283}
2016-04-06 08:39:24 +00:00
mstarzinger
b527ec119f [compiler] Ensure feedback vector before compiling.
This makes sure the type feedback vector is allocated and installed on
the SharedFunctionInfo before any of the compilers are being called.
Note that this now allows for an object state where a function is not
compiled but has a valid feedback vector is installed. This is working
as intended and supported by the rest of the system.

R=mvstanton@chromium.org

Review URL: https://codereview.chromium.org/1857203002

Cr-Commit-Position: refs/heads/master@{#35265}
2016-04-05 14:30:39 +00:00
mstarzinger
0ce296f180 [interpreter] Rely on SharedFunctionInfo in UseIgnition.
This makes sure the SharedFunctionInfo is available whenever we evaluate
the UseIgnition predicate. This makes sure we can apply filters properly
even when the interpreter causes eager compilation (instead of lazy).

R=rmcilroy@chromium.org

Review URL: https://codereview.chromium.org/1860943002

Cr-Commit-Position: refs/heads/master@{#35263}
2016-04-05 14:08:00 +00:00
machenbach
cf951dfb37 Revert of Correctly annotate eval origin. (patchset #4 id:60001 of https://codereview.chromium.org/1854713002/ )
Reason for revert:
[Sheriff] Crashes a layout test:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/5855

Original issue's description:
> Correctly annotate eval origin.
>
> There were a couple of issues with it:
> - interpreter is not supported
> - the source position was just accidentally correct for full-codegen
> - the eval origin could have been cached
>
> Also fixes a few other places to use AbstractCode.
>
> R=mstarzinger@chromium.org
>
> Committed: https://crrev.com/2f3a171adc9e620c2235bf0562145b9d4eaba66d
> Cr-Commit-Position: refs/heads/master@{#35257}

TBR=mstarzinger@chromium.org,yangguo@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/1858773004

Cr-Commit-Position: refs/heads/master@{#35260}
2016-04-05 13:01:17 +00:00
yangguo
2f3a171adc Correctly annotate eval origin.
There were a couple of issues with it:
- interpreter is not supported
- the source position was just accidentally correct for full-codegen
- the eval origin could have been cached

Also fixes a few other places to use AbstractCode.

R=mstarzinger@chromium.org

Review URL: https://codereview.chromium.org/1854713002

Cr-Commit-Position: refs/heads/master@{#35257}
2016-04-05 11:31:44 +00:00
jochen
cb7aa79b12 Expose a lower bound of malloc'd memory via heap statistics
We expect that the majority of malloc'd memory held by V8 is allocated
in Zone objects. Introduce an Allocator class that is used by Zones to
manage memory, and allows for querying the current usage.

BUG=none
R=titzer@chromium.org,bmeurer@chromium.org,jarin@chromium.org
LOG=n
TBR=rossberg@chromium.org

Review URL: https://codereview.chromium.org/1847543002

Cr-Commit-Position: refs/heads/master@{#35196}
2016-04-01 10:01:56 +00:00
rmcilroy
838cea4e4e [Interpreter] Make ignition compiler eagerly.
Makes --ignition cause eager compilation if we aren't building the startup
snapshot.

BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1811553003

Cr-Commit-Position: refs/heads/master@{#35066}
2016-03-24 18:38:24 +00:00
adamk
ed18aa65ea Remove support for legacy const, part 1
Now that ES2015 const has shipped, in Chrome 49, legacy const declarations
are no more. This lets us remove a bunch of code from many parts of the
codebase.

In this patch, I remove parser support for generating legacy const variables
from const declarations. This also removes the special "illegal declaration"
bit from Scope, which has ripples into all compiler backends.

Also gone are any tests which relied on legacy const declarations.

Note that we do still generate a Variable in mode CONST_LEGACY in one case:
function name bindings in sloppy mode. The likely fix there is to add a new
Variable::Kind for this case and handle it appropriately for stores in each
backend, but I leave that for a later patch to make this one completely
subtractive.

Review URL: https://codereview.chromium.org/1819123002

Cr-Commit-Position: refs/heads/master@{#35002}
2016-03-22 17:52:13 +00:00
mstarzinger
31d3c8a074 [compiler] Move PassesFilter onto SharedFunctionInfo.
The JSFunction::PassesFilter predicate is not fine-grained enough to
actually distinguish different closures and hence can be changed into
SharedFunctionInfo::PassesFilter instead. This will allow the compiler
to use is more broadly.

R=jkummerow@chromium.org

Review URL: https://codereview.chromium.org/1823033002

Cr-Commit-Position: refs/heads/master@{#34981}
2016-03-22 10:02:15 +00:00
mstarzinger
62d2aa45e4 [compiler] Move feedback vector allocation to pipeline.
This moves the call-sites that ensure we have a feedback vector present
before kicking off a compiler into the actual compilation pipeline. The
backends no longer need to worry about the feedback vector.

R=mvstanton@chromium.org

Review URL: https://codereview.chromium.org/1811973006

Cr-Commit-Position: refs/heads/master@{#34900}
2016-03-18 16:33:55 +00:00
mstarzinger
6691814f58 [compiler] Readability refactor of comilation pipeline.
This is a pure refactoring CL and should not contain any functional
changes to the code. The following has been done:
- Group compiler.cc into sections for each component.
- Surround local helper methods by anonymous namespace.
- Move implementation of Compiler (API class) together.

R=yangguo@chromium.org

Review URL: https://codereview.chromium.org/1809403002

Cr-Commit-Position: refs/heads/master@{#34891}
2016-03-18 13:57:42 +00:00
mstarzinger
8ba35e73ba [compiler] Remove redundant unoptimized compile trigger.
The trigger point in question is by now obsolete. The optimized compile
job will itself ensure that deoptimization support is present on the
incoming SharedFunctionInfo, this will make sure to produce baseline
code when necessary. The ScopeInfo is also installed at that point in
time.

R=yangguo@chromium.org

Review URL: https://codereview.chromium.org/1816513002

Cr-Commit-Position: refs/heads/master@{#34887}
2016-03-18 12:09:30 +00:00
mstarzinger
42c8812d15 [compiler] Allocate SharedFunctionInfo before compile.
This changes the compilation pipeline so that SharedFunctionInfo objects
are always allocated before the various compilers are invoked. It is a
preparation towards having that object available during compile time and
hence reducing the dependency on FunctionLiteral and the need to copy a
lot of the information into the CompilationInfo.

Optimizing compilers already assume the SharedFunctionInfo is present
and the baseline compilers have other heap accesses sprinkled throughout
the compilation process. Duplicating statically available information
from the SharedFunctionInfo within the CompilationInfo has no benefit.

R=yangguo@chromium.org

Review URL: https://codereview.chromium.org/1813803002

Cr-Commit-Position: refs/heads/master@{#34885}
2016-03-18 10:48:12 +00:00
mstarzinger
c5fcc5fc1f [compiler] Remove CompilationInfo::unoptimized_code field.
R=yangguo@chromium.org

Review URL: https://codereview.chromium.org/1812923002

Cr-Commit-Position: refs/heads/master@{#34881}
2016-03-18 07:57:32 +00:00
rmcilroy
6bdb970512 [Interpreter]: Move builtin-id from function_data to function_identifier.
Functions with builtin ids can be compiled with Ignition, so it is no longer
an option to overlap the bytecode_array field with the builtin id on
the SharedFunctionInfo object. Instead overlap it with the
inferred_name, which is only used for debug and so shouldn't be required
for functions with builtin ids. This result in the inferred_name field
being renamed to function_identifier, and adding typed accessors for
inferred_name and builtin_function_id.

This is required to build the snapshot with --no-lazy.

BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1801023002

Cr-Commit-Position: refs/heads/master@{#34867}
2016-03-17 16:37:59 +00:00
yangguo
6e8958fff4 [serializer] ensure that immortal immovable roots are correctly deserialized.
Immortal immovable roots must be allocated on the first page of the space.
If serializing the root list exceeds the first page, immortal immovable root
objects might end up outside of the first page. That could cause missing
write barriers.

We now iterate the root list twice. The first time we only serialize immortal
immovable root objects. The second time we serialize the rest.

R=mstarzinger@chromium.org

Review URL: https://codereview.chromium.org/1811913002

Cr-Commit-Position: refs/heads/master@{#34859}
2016-03-17 13:16:25 +00:00
adamk
5a202cce6e Remove --harmony-modules flag and let embedder decide when modules are used
Modules already have a separate entrypoint into the engine (at the moment,
this is v8::ScriptCompiler::CompileModule, though that will change to
something like ParseModule). This meant that requiring a commandline flag
simply added an extra complexity burden on embedders. By removing the v8
flag, this lets embedders use their own flagging mechanism (such as d8's
"--module", or Blink's RuntimeEnabledFeatures) to control whether
modules are to be used.

Also remove old modules tests that were being skipped (since they test
very old, pre-ES2015 modules syntax).

R=littledan@chromium.org
BUG=v8:1569, chromium:594639
LOG=y

Review URL: https://codereview.chromium.org/1804693002

Cr-Commit-Position: refs/heads/master@{#34764}
2016-03-15 00:45:00 +00:00
yangguo
bae3efface [serializer] add options to compile eagerly and pre-age for code cache.
R=vogelheim@chromium.org
BUG=chromium:594551
LOG=N

Review URL: https://codereview.chromium.org/1804433004

Cr-Commit-Position: refs/heads/master@{#34761}
2016-03-14 18:57:04 +00:00
mstarzinger
5bd307fa72 [compiler] Sidestep the interpreter for generator literals.
This is because compiler.cc is awesome. There are cases where we do not
yet have a SharedFunctionInfo that can tell us whether we are compiling
a generator function, we query the FunctionLiteral instead.

R=rmcilroy@chromium.org
BUG=v8:4681
LOG=n

Review URL: https://codereview.chromium.org/1780193002

Cr-Commit-Position: refs/heads/master@{#34677}
2016-03-10 14:35:40 +00:00
mstarzinger
855176533c [compiler] Sidestep optimizing of generator resumers.
This ensures our optimizing compilers as well as the interpreter are
never tasked with compiling the generator-resuming builtin methods. The
corresponding intrinsics for those methods are not supported and it is
not possible to provide a C++ reference implementation for them. We do
this by assigning builtin function ids to them that we can recognize
during the compiler dispatch.

Note that this also affects the interpreter, because methods having a
builtin function id assigned are not interpreted ({function_data} field
is overlapping). If this ever changes we can still do an early check in
the compiler dispatch (similar to the optimizing compilers) easily.

This applies to the following methods:
- Generator.prototype.next (calls Runtime_GeneratorNext).
- Generator.prototype.return (calls Runtime_GeneratorReturn).
- Generator.prototype.throw (calls Runtime_GeneratorThrow).

R=neis@chromium.org
BUG=v8:4681
LOG=n

Review URL: https://codereview.chromium.org/1779123003

Cr-Commit-Position: refs/heads/master@{#34675}
2016-03-10 14:07:10 +00:00
mstarzinger
899105c0bc [compiler] Sidestep the interpreter for generator functions.
This ensures the interpreter is not tasked with compiling generator
functions. It currently does not support suspending activations at
yielding points, but we still want to be able to activate it for the
rest of JavaScript in the meantime.

R=rmcilroy@chromium.org
BUG=v8:4681
LOG=n

Review URL: https://codereview.chromium.org/1782013002

Cr-Commit-Position: refs/heads/master@{#34672}
2016-03-10 13:21:51 +00:00
rossberg
4614c7caaf [strong] Remove all remainders of strong mode
R=mstarzinger@chromium.org,bmeurer@chromium.org,adamk@chromium.org
BUG=v8:3956
LOG=Y

Review URL: https://codereview.chromium.org/1773653002

Cr-Commit-Position: refs/heads/master@{#34669}
2016-03-10 12:45:42 +00:00
ssanfilippo
8447072d60 [Interpreter] Log code-creation events for bytecode handlers.
BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1772403002

Cr-Commit-Position: refs/heads/master@{#34631}
2016-03-09 16:52:19 +00:00
mstarzinger
46bd989a3a [compiler] Unify naming of methods in compiler API.
This is a pure refactoring and renaming of methods in the compiler API
with the goal to increase readability. Also the compiler API is moved to
the top of the file, as it is the central piece in that file.

R=yangguo@chromium.org

Review URL: https://codereview.chromium.org/1766623004

Cr-Commit-Position: refs/heads/master@{#34579}
2016-03-08 12:09:10 +00:00
mstarzinger
cabe6844c2 [compiler] Slightly change API to finalize compile jobs.
This changes the compiler API that finalizes a previously queued
optimization job on the main thread, to not deal with code objects
directly. This is in sync with the rest of the API now.

R=yangguo@chromium.org

Review URL: https://codereview.chromium.org/1773663003

Cr-Commit-Position: refs/heads/master@{#34577}
2016-03-08 10:10:53 +00:00
mstarzinger
2669224274 [compiler] Remove support for concurrent OSR.
R=yangguo@chromium.org

Review URL: https://codereview.chromium.org/1773593002

Cr-Commit-Position: refs/heads/master@{#34572}
2016-03-08 09:02:44 +00:00
danno
9dcd0857d6 [runtime] Unify and simplify how frames are marked
Before this CL, various code stubs used different techniques
for marking their frames to enable stack-crawling and other
access to data in the frame. All of them were based on a abuse
of the "standard" frame representation, e.g. storing the a
context pointer immediately below the frame's fp, and a
function pointer after that. Although functional, this approach
tends to make stubs and builtins do an awkward, unnecessary
dance to appear like standard frames, even if they have
nothing to do with JavaScript execution.

This CL attempts to improve this by:

* Ensuring that there are only two fundamentally different
  types of frames, a "standard" frame and a "typed" frame.
  Standard frames, as before, contain both a context and
  function pointer. Typed frames contain only a minimum
  of a smi marker in the position immediately below the fp
  where the context is in standard frames.
* Only interpreted, full codegen, and optimized Crankshaft and
  TurboFan JavaScript frames use the "standard" format. All
  other frames use the type frame format with an explicit
  marker.
* Typed frames can contain one or more values below the
  type marker. There is new magic macro machinery in
  frames.h that simplifies defining the offsets of these fields
  in typed frames.
* A new flag in the CallDescriptor enables specifying whether
  a frame is a standard frame or a typed frame. Secondary
  register location spilling is now only enabled for standard
  frames.
* A zillion places in the code have been updated to deal with
  the fact that most code stubs and internal frames use the
  typed frame format. This includes changes in the
  deoptimizer, debugger, and liveedit.
* StandardFrameConstants::kMarkerOffset is deprecated,
  (CommonFrameConstants::kContextOrFrameTypeOffset
  and StandardFrameConstants::kFrameOffset are now used
  in its stead).

LOG=N

Review URL: https://codereview.chromium.org/1696043002

Cr-Commit-Position: refs/heads/master@{#34571}
2016-03-08 08:36:36 +00:00
mstarzinger
1d7da9c639 [compiler] Move JSFunction post-instantiation tasks.
This moves the post-instantiation work performed on newly allocated
JSFunction objects into the Compiler class. The aim is to eventually
have all decisions how to compile functions be centralized within the
compiler pipeline.

R=mvstanton@chromium.org

Review URL: https://codereview.chromium.org/1764023003

Cr-Commit-Position: refs/heads/master@{#34550}
2016-03-07 16:26:25 +00:00
mstarzinger
970f1ae610 [compiler] Better description of compiler API.
This adds more comments to the V8 compiler API explaining the entry
methods within that API. It also establishes a separate method for OSR
compilation since {Compiler::GetOptimizedCode} is only used for OSR by
now.

R=danno@chromium.org

Review URL: https://codereview.chromium.org/1769523002

Cr-Commit-Position: refs/heads/master@{#34503}
2016-03-04 16:11:09 +00:00
mstarzinger
d0b67b984e [compiler] Reduce number of entry points into compiler API.
This removes the entry point to the compiler API which allows requesting
lazily compiled full-codegen code. The aim is to eventually allow the
decisions of which baseline compiler should be used (e.g. Ignition or
full-codegen) be centralized within the compiler pipeline.

R=bmeurer@chromium.org

Review URL: https://codereview.chromium.org/1764963002

Cr-Commit-Position: refs/heads/master@{#34489}
2016-03-04 10:45:40 +00:00
mstarzinger
8377ce9552 [crankshaft] Move CompilationPhase into separate file.
The CompilationPhase helper class is only used in Crankshaft and is not
suitable for use in other compilers. This factors is out into a separate
file and moves it into the "crankshaft" directory.

R=jkummerow@chromium.org

Review URL: https://codereview.chromium.org/1758773002

Cr-Commit-Position: refs/heads/master@{#34441}
2016-03-02 17:32:03 +00:00
mstarzinger
56eca6d315 [crankshaft] Remove graph builder from optimized compile job.
There is no reason to keep around the HOptimizedGraphBuilder after the
graph has successfully been built. Later phases in OptimizedCompileJob
should not rely on it anymore.

R=jkummerow@chromium.org

Review URL: https://codereview.chromium.org/1756183002

Cr-Commit-Position: refs/heads/master@{#34440}
2016-03-02 17:27:38 +00:00
jkummerow
4af7757fdf When Crankshaft aborts compilation, use TurboFan next time
When we try to optimize a function with Crankshaft, but compilation
bails out, don't disable optimization for that function entirely,
just disable Crankshaft, so TurboFan will be used for the next attempt.

Thereby this widens the TurboFan intake valve.

Review URL: https://codereview.chromium.org/1751873002

Cr-Commit-Position: refs/heads/master@{#34396}
2016-03-01 15:14:00 +00:00
yangguo
6f17848caa [serializer] split up src/snapshot/serialize.*
R=rossberg@chromium.org, ulan@chromium.org, vogelheim@chromium.org

Review URL: https://codereview.chromium.org/1751863002

Cr-Commit-Position: refs/heads/master@{#34395}
2016-03-01 14:44:08 +00:00
rmcilroy
cb29f9cdbc [Interpreter] Add support for cpu profiler logging.
Adds support for cpu profiler logging to the interpreter. Modifies the
the API to be passed AbstractCode objects instead of Code objects, and
adds extra functions to AbstractCode which is required by log.cc and
cpu-profiler.cc.

The main change in sampler.cc is to determine if a stack frame is an
interpreter stack frame, and if so, use the bytecode address as the pc
for that frame. This allows sampling of bytecode functions. This
requires adding support to SafeStackIterator to determine if a frame is
interpreted, which we do by checking the PC against pre-stored addresses
for the start and end of interpreter entry builtins.

Also removes CodeDeleteEvents which are dead code and haven't
been reported for some time.

Still to do is tracking source positions which will be done in a
followup CL.

BUG=v8:4766
LOG=N

Review URL: https://codereview.chromium.org/1728593002

Cr-Commit-Position: refs/heads/master@{#34321}
2016-02-26 11:04:55 +00:00
mstarzinger
6acee6ee59 [interpreter] Make setting of function data more resilient.
This adds explicit setters for the SharedFunctionInfo::function_data
field. Such setters are safer because they allow for explicit checking
of which values are allowed, and they improve readability because the
intended semantics become clear for each call-site. Also fix a cctest
case along the way.

R=rmcilroy@chromium.org

Review URL: https://codereview.chromium.org/1730853005

Cr-Commit-Position: refs/heads/master@{#34297}
2016-02-25 16:07:24 +00:00
bmeurer
bda527b5ff [turbofan] Add support for SOFT deopts and use that for property access.
Up until now we were unable to (re)optimize code when we hit
uninitialized (Keyed)Load/StoreICs in the code. We always put an IC
there (sharing the feedback vector with fullcodegen at least) and called
it a day. But we never deoptimized the code object when we gathered more
feedback. This doesn't work very well in practice, esp. with hot code
relying on this. So until we have a proper mechanism to express the need
to reoptimize after we gathered additional feedback from optimized code,
we follow the Crankshaft approach instead and install a SOFT deopt, so
we can not only learn but also utilize the new feedback.

R=mstarzinger@chromium.org
BUG=v8:4470
LOG=n

Review URL: https://codereview.chromium.org/1518013002

Cr-Commit-Position: refs/heads/master@{#34178}
2016-02-20 19:06:20 +00:00
fmeawad
c6279388c7 Split the TRACE_EVENTs from the LOG/HistogramTimers/TimerEvents functionality.
This CL adds a TRACE_EVENT where there is an isolated LOG, a HistogramTimer
or a TimerEvent.

Once we have a d8 tracing controller, all TimerEvents will be removed since
they do not provide an added value over TRACE_EVENTs. HistogramTimers will
remain, but their functionality will be limited to Histograms only.

BUG=v8:4562
LOG=N

Review URL: https://codereview.chromium.org/1707563002

Cr-Commit-Position: refs/heads/master@{#34099}
2016-02-18 06:13:33 +00:00
cbruni
8eb09facb5 [counters] adding more counters and trace-events
V8 tracks already most useful information, but lacks proper tracing scopes
that make it possible to distinguish certain events from each other.
- add trace-scope to track lazy-parsing due to optimization
- add trace-scope to track code optimization

BUG=

Review URL: https://codereview.chromium.org/1661883003

Cr-Commit-Position: refs/heads/master@{#34002}
2016-02-15 17:29:32 +00:00
mstarzinger
1986a486bf [interpreter] CompilationInfo::unoptimized_code only for OSR.
The field in question is only needed when the optimizing compiler is
triggered via OSR. All other paths (e.g. from bytecode stream) should
not rely on the unoptimized code being present.

R=yangguo@chromium.org

Review URL: https://codereview.chromium.org/1685633002

Cr-Commit-Position: refs/heads/master@{#33860}
2016-02-10 10:28:12 +00:00
mstarzinger
582be2ba09 [interpreter] Make it possible to optimize without parse.
This makes sure we can run through the TurboFan pipeline without having
to parse the source when using the bytecode stream as input. This path
is now being tested by the BytecodeGraphTester helper.

R=titzer@chromium.org,rmcilroy@chromium.org

Review URL: https://codereview.chromium.org/1679313002

Cr-Commit-Position: refs/heads/master@{#33856}
2016-02-10 09:16:38 +00:00
mstarzinger
b881c908a1 Switch GetConcurrentlyOptimizedCode to MaybeHandle.
The function in question can already return an empty handle in the case
of failures. This makes that contract explicit by using MaybeHandle like
all other compiler API functions.

R=yangguo@chromium.org

Review URL: https://codereview.chromium.org/1590963002

Cr-Commit-Position: refs/heads/master@{#33839}
2016-02-09 09:47:57 +00:00
yangguo
8a2d571734 [bootstrapper] extra natives must not use natives syntax.
R=bmeurer@chromium.org, domenic@chromium.org

Review URL: https://codereview.chromium.org/1670923003

Cr-Commit-Position: refs/heads/master@{#33770}
2016-02-05 12:33:55 +00:00
mvstanton
3f36e658c8 Revert of Type Feedback Vector lives in the closure (patchset #2 id:40001 of https://codereview.chromium.org/1668103002/ )
Reason for revert:
Must revert for now due to chromium api natives issues.

Original issue's description:
> Type Feedback Vector lives in the closure
>
> (RELAND: the problem before was a missing write barrier for adding the code
> entry to the new closure. It's been addressed with a new macro instruction
> and test. The only change to this CL is the addition of two calls to
> __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
> Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
> And Benedikt reviewed it as well.
>
> TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org
>
> BUG=
>
> Committed: https://crrev.com/bb31db3ad6de16f86a61f6c7bbfd3274e3d957b5
> Cr-Commit-Position: refs/heads/master@{#33741}

TBR=bmeurer@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/1670813005

Cr-Commit-Position: refs/heads/master@{#33766}
2016-02-05 10:48:35 +00:00
mvstanton
bb31db3ad6 Type Feedback Vector lives in the closure
(RELAND: the problem before was a missing write barrier for adding the code
entry to the new closure. It's been addressed with a new macro instruction
and test. The only change to this CL is the addition of two calls to
__ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)

We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.

We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.

This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.

The heap change is trivial so I TBR Hannes for it...
Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
And Benedikt reviewed it as well.

TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org

BUG=

Review URL: https://codereview.chromium.org/1668103002

Cr-Commit-Position: refs/heads/master@{#33741}
2016-02-04 15:41:23 +00:00
rmcilroy
72d768d1f9 Add counters to trace baseline code size.
BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1649743002

Cr-Commit-Position: refs/heads/master@{#33688}
2016-02-02 16:51:46 +00:00
mvstanton
a702785156 Revert of Type Feedback Vector lives in the closure (patchset #2 id:20001 of https://codereview.chromium.org/1642613002/ )
Reason for revert:
Bug: failing to use write barrier when writing code entry into closure.

Original issue's description:
> Reland of Type Feedback Vector lives in the closure
>
> (Fixed a bug found by nosnap builds.)
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
>
> TBR=hpayer@chromium.org
> BUG=
>
> Committed: https://crrev.com/d984b3b0ce91e55800f5323b4bb32a06f8a5aab1
> Cr-Commit-Position: refs/heads/master@{#33548}

TBR=bmeurer@chromium.org,yangguo@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/1643533003

Cr-Commit-Position: refs/heads/master@{#33556}
2016-01-27 15:05:38 +00:00
mvstanton
d984b3b0ce Reland of Type Feedback Vector lives in the closure
(Fixed a bug found by nosnap builds.)

We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.

We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.

This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.

The heap change is trivial so I TBR Hannes for it...

TBR=hpayer@chromium.org
BUG=

Review URL: https://codereview.chromium.org/1642613002

Cr-Commit-Position: refs/heads/master@{#33548}
2016-01-27 12:53:42 +00:00
mvstanton
e2e7dc32ef Revert of Type Feedback Vector lives in the closure (patchset #12 id:260001 of https://codereview.chromium.org/1563213002/ )
Reason for revert:
FAilure on win32 bot, need to investigate webkit failures.

Original issue's description:
> Type Feedback Vector lives in the closure
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
>
> TBR=hpayer@chromium.org
>
> BUG=
>
> Committed: https://crrev.com/a5200f7ed4d11c6b882fa667da7a1864226544b4
> Cr-Commit-Position: refs/heads/master@{#33518}

TBR=bmeurer@chromium.org,akos.palfi@imgtec.com
# 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/1632993003

Cr-Commit-Position: refs/heads/master@{#33520}
2016-01-26 15:02:29 +00:00
mvstanton
a5200f7ed4 Type Feedback Vector lives in the closure
We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.

We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.

This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.

The heap change is trivial so I TBR Hannes for it...

TBR=hpayer@chromium.org

BUG=

Review URL: https://codereview.chromium.org/1563213002

Cr-Commit-Position: refs/heads/master@{#33518}
2016-01-26 14:21:08 +00:00
rmcilroy
befe61fa3e [Interpreter] Add native function literal support.
Adds support for calling native function literals. Moves the logic for building
the native function's SharedFunctionInfo out of full-codegen into compiler.cc
to allow it to be shared between fullcodegen and Ignition.

BUG=v8:4686
LOG=N

Review URL: https://codereview.chromium.org/1635553002

Cr-Commit-Position: refs/heads/master@{#33510}
2016-01-26 11:30:46 +00:00
mstarzinger
b707ca4b54 [interpreter] Deprecate --ignition-fallback-on-catch flag.
The current support for try-catch in the interpreter can handle most of
the cases appearing in our test suite. Also the flag in question did not
detect try-finally constructs. This removes the flag and instead extends
the test expectations.

R=rmcilroy@chromium.org
BUG=v8:4674
LOG=n

Review URL: https://codereview.chromium.org/1631593003

Cr-Commit-Position: refs/heads/master@{#33494}
2016-01-25 15:57:51 +00:00
danno
d1d0196473 [compiler] Remove CodeStub from CompilationInfo
The motivation for this is that CompilationInfo really shouldn't
explicitly know anything about CodeStubs. This is evident in
the TurboFan stubs pipeline, which only needs to pass down
information about Code::Flags to the code generator and not
any of the CallInterfaceDescriptor silliness that Hydrogen has
to push around, since TF has the Linkage class that
encapsulates everything that is needed for the stub ABI. So,
instead of threading CodeStub machinery through the TF stub
pipeline, it is now removed from CompilationInfo and replaced
by only the explicit bits needed both by the Crankshaft and
TF pipelines in code generation.

Review URL: https://codereview.chromium.org/1604543002

Cr-Commit-Position: refs/heads/master@{#33410}
2016-01-20 15:18:14 +00:00
rmcilroy
43c02e49d8 [Interpreter] Change ignition fallback flag to only fallback on catch, not eval.
Now that we support eval in Ignition, remove the fallback for eval checks
and make the flag only fallback on catch blocks.

BUG=v8:4280,v8:4676
LOG=N

Review URL: https://codereview.chromium.org/1595223004

Cr-Commit-Position: refs/heads/master@{#33384}
2016-01-19 11:33:50 +00:00