Commit Graph

841 Commits

Author SHA1 Message Date
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
mstarzinger
8041a753ca Drop "current_code" from compiler API.
This removes the need to pass in the current unoptimized code when
requesting optimized code for a function. Note that the notion of
unoptimized code becomes moot when optimizing from the interpreter
bytecode, hence the API should not encode such a dependency.

R=bmeurer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#33353}
2016-01-18 10:24:22 +00:00
mstarzinger
0aeaf0cbd1 Move SourcePosition into separate header file.
This splits out the SourcePosition class into a separate header file.
Reason for this refactoring is that said class is mostly used by the
Crankshaft compiler and not needed for all compilers. Also having the
assembler depend on the class creates a dependency cycle.

R=bmeurer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#33325}
2016-01-15 12:11:50 +00:00
jarin
964964541d [turbofan] Fix turbofan-enabling conditions.
This restricts turbofan to turbofan-supported subset for the shipping
configuration ("use asm" and features unsupported by Crankshaft).

Without this, we compile with Turbofan even when there is
try-catch-finally as long as the function is "use asm" or
it contains a feature unsupported by crankshaft but supported
by turbofan (e.g., 'with' statement).

BUG=

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

Cr-Commit-Position: refs/heads/master@{#33085}
2016-01-04 14:53:07 +00:00
bmeurer
84a88a1bd0 [turbofan] Port Crankshaft's weak objects mechanism to TurboFan.
Use the same mechanism that is already available for Crankshaft to not
leak all kinds of things in TurboFan generated code. Long-term we will
support weakness in a better way, but for now, just use the
infrastructure that is already in place to avoid memory leaks via
TurboFan generated code.

R=jarin@chromium.org, ulan@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#33073}
2016-01-04 07:12:35 +00:00
bmeurer
97def8070c [runtime] Introduce dedicated JSBoundFunction to represent bound functions.
According to the ES2015 specification, bound functions are exotic
objects, and thus don't need to be implemented as JSFunctions. So
we introduce a new JSBoundFunction type to represent bound functions
and make them optimizable. This already improves the performance of
calling or constructing bound functions by 10-100x depending on the
use case because we avoid the crazy dance between JavaScript and C++
that was implemented in v8natives.js previously.

There's still room for improvement in the performance of actually
creating bound functions, which is also relevant in practice, but
we already have a plan how to accomplish that later.

The mips/mips64 ports were contributed by akos.palfi@imgtec.com.

CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
BUG=chromium:535408, chromium:571299, v8:4629
LOG=n

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

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

Cr-Commit-Position: refs/heads/master@{#33044}
2015-12-27 06:31:44 +00:00
bmeurer
1cf8b105d6 Revert of [runtime] Introduce dedicated JSBoundFunction to represent bound functions. (patchset #14 id:260001 of https://codereview.chromium.org/1542963002/ )
Reason for revert:
Breaks arm64 sim nosnap: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20nosnap%20-%20debug/builds/805/steps/Check/logs/function-bind

Original issue's description:
> [runtime] Introduce dedicated JSBoundFunction to represent bound functions.
>
> According to the ES2015 specification, bound functions are exotic
> objects, and thus don't need to be implemented as JSFunctions. So
> we introduce a new JSBoundFunction type to represent bound functions
> and make them optimizable. This already improves the performance of
> calling or constructing bound functions by 10-100x depending on the
> use case because we avoid the crazy dance between JavaScript and C++
> that was implemented in v8natives.js previously.
>
> There's still room for improvement in the performance of actually
> creating bound functions, which is also relevant in practice, but
> we already have a plan how to accomplish that later.
>
> The mips/mips64 ports were contributed by akos.palfi@imgtec.com.
>
> CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
> BUG=chromium:535408, chromium:571299, v8:4629
> LOG=n
>
> Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2
> Cr-Commit-Position: refs/heads/master@{#33042}

TBR=cbruni@chromium.org,hpayer@chromium.org,yangguo@chromium.org,akos.palfi@imgtec.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:535408, chromium:571299, v8:4629

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

Cr-Commit-Position: refs/heads/master@{#33043}
2015-12-27 04:42:13 +00:00
bmeurer
ca8623eaa4 [runtime] Introduce dedicated JSBoundFunction to represent bound functions.
According to the ES2015 specification, bound functions are exotic
objects, and thus don't need to be implemented as JSFunctions. So
we introduce a new JSBoundFunction type to represent bound functions
and make them optimizable. This already improves the performance of
calling or constructing bound functions by 10-100x depending on the
use case because we avoid the crazy dance between JavaScript and C++
that was implemented in v8natives.js previously.

There's still room for improvement in the performance of actually
creating bound functions, which is also relevant in practice, but
we already have a plan how to accomplish that later.

The mips/mips64 ports were contributed by akos.palfi@imgtec.com.

CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
BUG=chromium:535408, chromium:571299, v8:4629
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#33042}
2015-12-26 20:28:17 +00:00
mstarzinger
1e385a832a [interpreter] Use interpreter on all function literals.
This fixes a path in the compilation pipeline that side-stepped the
interpreter when a function literal was eagerly compiled. This caused
the interpreter to miss some test coverage.

R=rmcilroy@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#32867}
2015-12-15 14:12:51 +00:00
mstarzinger
3b52a53773 [interpreter] Unify decision how to compile baseline code.
This unifies the decision whether to use Ignition or FullCodeGenerator
to generate baseline code into a single place. This allows for small
function literals that are compiled eagerly to go through Ignition.

R=rmcilroy@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#32848}
2015-12-14 20:58:32 +00:00
mstarzinger
4c7a51d759 Deprecate ability to generate stubs via Compiler class.
This removes the ability to generate stub code via the full-fledged
compiler pipeline that parses and analyzes JavaScript source code.
Generation of stub code has been moved to a lower-level entry point.

R=bmeurer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#32847}
2015-12-14 19:19:22 +00:00
yangguo
e1866c8f6f [debugger] fix liveedit in combination with step in.
R=verwaest@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#32517}
2015-12-02 14:27:09 +00:00
rossberg
199bbdb40f Create ast/ and parsing/ subdirectories and move appropriate files
Moves all files related to AST and scopes into ast/,
and all files related to scanner & parser to parsing/.

Also eliminates a couple of spurious dependencies.

R=mstarzinger@chromium.org
BUG=

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

Cr-Commit-Position: refs/heads/master@{#32351}
2015-11-26 16:23:07 +00:00
verwaest
8e28e851ee Install ConstructNonConstructable as construct stub for non-constructables.
BUG=

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

Cr-Commit-Position: refs/heads/master@{#32223}
2015-11-24 17:17:00 +00:00
rmcilroy
fb9ad89fea [Interpreter]: Add ignition blacklist to mjsunit.status and test262.status.
Adds a blacklist of tests which are currently unsupported or broken in Ignition to
the mjsunit and test262 test status.

Also removes --ignition-script-filter flag, and adds a
--ignition_fallback_on_eval_and_catch flag which fallsback to fullcodegen for
functions which call eval or contain a catch block.

BUG=v8:4280
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#31864}
2015-11-06 18:52:51 +00:00
verwaest
4ab1b05d5e Remove receiver conversion from function prologue
Depends on https://codereview.chromium.org/1407373007/
After that CL, all receiver conversion is handled by the call builtin.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#31826}
2015-11-05 13:23:51 +00:00
rmcilroy
e4b4dd41ed [Interpreter] Don't compile Api or Builtin id functions through the interpreter.
The Interpreter uses the function_data slot in the shared function info, so
can't be used to compile functions which use that field for other reasons,
such as API functions or functions with builtin function ids.

BUG=v8:4280
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#31721}
2015-11-02 20:38:18 +00:00
yangguo
67dc6ce5fd Canonicalize handles for optimized compilation.
R=bmeurer@chromium.org

Committed: https://crrev.com/15f36b2b1e166a511966a9991fddea94f890a755
Cr-Commit-Position: refs/heads/master@{#31566}

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

Cr-Commit-Position: refs/heads/master@{#31576}
2015-10-26 15:33:20 +00:00
yangguo
8bcef0d73d Revert of Canonicalize handles for optimized compilation. (patchset #1 id:1 of https://codereview.chromium.org/1423833003/ )
Reason for revert:
GC stress failure on ia32 optdebug:

/tmp/runfswAKT/out/Debug/d8 --test --random-seed=-1536184370 --turbo --always-opt --nohard-abort --nodead-code-elimination --nofold-constants --enable-slow-asserts --debug-code --verify-heap --stack-size=46 /tmp/runfswAKT/test/mjsunit/mjsunit.js /tmp/runfswAKT/test/mjsunit/regress/regress-1132.js --gc-interval=500 --stress-compaction --concurrent-recompilation-queue-length=64 --concurrent-recompilation-delay=500 --concurrent-recompilation

Run #1
Exit code: -6
Result: FAIL
Expected outcomes: PASS
Duration: 00:06:279

Stderr:

#
# Fatal error in ../../src/hashmap.h, line 248
# Check failed: base::bits::IsPowerOfTwo32(capacity_).
#

==== C stack trace ===============================

Original issue's description:
> Canonicalize handles for optimized compilation.
>
> R=bmeurer@chromium.org
>
> Committed: https://crrev.com/15f36b2b1e166a511966a9991fddea94f890a755
> Cr-Commit-Position: refs/heads/master@{#31566}

TBR=jochen@chromium.org,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

Cr-Commit-Position: refs/heads/master@{#31570}
2015-10-26 14:45:34 +00:00
yangguo
15f36b2b1e Canonicalize handles for optimized compilation.
R=bmeurer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#31566}
2015-10-26 13:50:16 +00:00
Benedikt Meurer
71bde166b1 [turbofan] Remove obsolete JSTypeFeedbackSpecializer and JSTypeFeedbackLowering.
Both the JSTypeFeedbackSpecializer and the JSTypeFeedbackLowering is
dead code by now, since the more general JSNativeContextSpecialization
deals with the property/global load/store type feedback in a way that
also interacts properly with inlining.

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

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

Cr-Commit-Position: refs/heads/master@{#31462}
2015-10-22 10:24:27 +00:00
jkummerow
81ee94b650 Move Hydrogen and Lithium to src/crankshaft/
Review URL: https://codereview.chromium.org/1405363003

Cr-Commit-Position: refs/heads/master@{#31410}
2015-10-20 13:25:55 +00:00
adamk
4937cc9457 Remove unused Zone argument from InitializeAstVisitor
This adds a bit of boilerplate to some AstVisitors (they now have to
declare their own zone_ member and zone() accessor), but makes it clearer
what DEFINE_AST_VISITOR_SUBCLASS_MEMBERS is for: stack limit checking.

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

Cr-Commit-Position: refs/heads/master@{#31287}
2015-10-15 10:34:28 +00:00
bmeurer
ffd0a2ae74 [turbofan] Make native context specialization dependent on the typed pipeline.
Also refactor the JSGlobalSpecialization somewhat to reduce the amount
of duplicated code somewhat.

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

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

Cr-Commit-Position: refs/heads/master@{#31286}
2015-10-15 10:25:47 +00:00
yangguo
c7c7b598ee Serializer: remove unused --serialize-inner flag.
R=vogelheim@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#31280}
2015-10-15 08:47:19 +00:00
bmeurer
1262a41c1f [turbofan] Disable native context specialization for the asm.js pipeline.
R=jarin@chromium.org
BUG=v8:4470
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#31247}
2015-10-14 05:51:24 +00:00
mvstanton
76bee80672 Remove FLAG_cache_optimized_code because we always have it on.
The data structure that holds the optimized code is becoming essential for
additional functionality, too.

R=mstarzinger@chromium.org
BUG=

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

Cr-Commit-Position: refs/heads/master@{#31216}
2015-10-12 16:10:59 +00:00
rmcilroy
6e64a057e3 [Interpreter] Add ignition-script-filter flag to filter scripts.
Add a flag to explicitly filter scripts in ignition and use it for the test262
variant. The previous approach of overloading ignition-filter meant that only
top-level code was getting compiled through ignition.

BUG=v8:4280
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#31164}
2015-10-07 19:08:37 +00:00
mstarzinger
6c97e54f27 [interpreter] Make --ignition-filter script filtering explicit.
This makes it explicit when the --ignition-filter pattern should be
applied to the script name instead of the function name by using a
proper "s:{name}" pattern. It also hardcodes it to be a prefix match
instead of an exact match, because that is all we need for test262.

R=rmcilroy@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#31153}
2015-10-07 14:27:37 +00:00
bmeurer
e16dd13d6d [turbofan] Add initial support for global specialization.
Introduce a new JSGlobalSpecialization advanced reducer that runs
during the initial inlining and context specialization, and specializes
the graph to the globals of the native context.  Currently we assume
that we do not inline cross native context, but long-term we will grab
the global object from the JSLoadGlobal/JSStoreGlobal feedback (with the
new global load/store ICs that are currently in the workings), and then
this whole specialization will be fully compositional even across
cross-context inlining.

Note that we cannot really handle most of the stores to global object
property cells because TurboFan doesn't have a mechanism to enforce
certain representations.  Also note that we cannot yet fully benefit
from the type feedback collected on the global object property cells,
because the type system cannot deal with maps in a reasonable way.

CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel
R=jarin@chromium.org
BUG=v8:4470
LOG=n

Committed: https://crrev.com/6fbf7903f94924ea066af481719898bd9667b6eb
Cr-Commit-Position: refs/heads/master@{#31139}

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

Cr-Commit-Position: refs/heads/master@{#31148}
2015-10-07 12:10:54 +00:00
bmeurer
84065c5f1e Revert of [turbofan] Add initial support for global specialization. (patchset #4 id:60001 of https://codereview.chromium.org/1387393002/ )
Reason for revert:
Breaks GC stress: http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/1984/steps/Bisect%20c5528ac1.Retry/logs/regress-crbug-450960

Original issue's description:
> [turbofan] Add initial support for global specialization.
>
> Introduce a new JSGlobalSpecialization advanced reducer that runs
> during the initial inlining and context specialization, and specializes
> the graph to the globals of the native context.  Currently we assume
> that we do not inline cross native context, but long-term we will grab
> the global object from the JSLoadGlobal/JSStoreGlobal feedback (with the
> new global load/store ICs that are currently in the workings), and then
> this whole specialization will be fully compositional even across
> cross-context inlining.
>
> Note that we cannot really handle most of the stores to global object
> property cells because TurboFan doesn't have a mechanism to enforce
> certain representations.  Also note that we cannot yet fully benefit
> from the type feedback collected on the global object property cells,
> because the type system cannot deal with maps in a reasonable way.
>
> CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel
> R=jarin@chromium.org
> BUG=v8:4470
> LOG=n
>
> Committed: https://crrev.com/6fbf7903f94924ea066af481719898bd9667b6eb
> Cr-Commit-Position: refs/heads/master@{#31139}

TBR=jarin@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4470

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

Cr-Commit-Position: refs/heads/master@{#31144}
2015-10-07 11:42:21 +00:00
ishell
1d7c9c8139 The metadata part of TypeFeedbackVector is extracted to TypeFeedbackMetadata array.
Thus TypeFeedbackMetadata can now be shared between different native contexts.

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

Cr-Commit-Position: refs/heads/master@{#31143}
2015-10-07 10:33:32 +00:00
rmcilroy
c5528ac1cb [Interpreter] Support top-level code.
Adds support for compiling top level code to bytecode to be run in the
interpreter.

Also moves PassesFilter to String:: so that it can be used to filter top
level script names as well as functions (used in
https://codereview.chromium.org/1379093002/)

BUG=v8:4280
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#31142}
2015-10-07 10:30:48 +00:00
bmeurer
6fbf7903f9 [turbofan] Add initial support for global specialization.
Introduce a new JSGlobalSpecialization advanced reducer that runs
during the initial inlining and context specialization, and specializes
the graph to the globals of the native context.  Currently we assume
that we do not inline cross native context, but long-term we will grab
the global object from the JSLoadGlobal/JSStoreGlobal feedback (with the
new global load/store ICs that are currently in the workings), and then
this whole specialization will be fully compositional even across
cross-context inlining.

Note that we cannot really handle most of the stores to global object
property cells because TurboFan doesn't have a mechanism to enforce
certain representations.  Also note that we cannot yet fully benefit
from the type feedback collected on the global object property cells,
because the type system cannot deal with maps in a reasonable way.

CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel
R=jarin@chromium.org
BUG=v8:4470
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#31139}
2015-10-07 10:26:11 +00:00