Commit Graph

50 Commits

Author SHA1 Message Date
Ross McIlroy
ed592eb03f [Cleanup][Interpreter] Move feedback slot allocation to bytecode generator
Moves the feedback vector slot allocation out of ast-numbering and into
bytecode generation directly. This has a couple of benifits, including reduced
AST size, avoid code duplication and reduced feedback vector sizes in many cases
due to only allocating slots when needed. Also removes AstProperties since
this is no longer needed.

AstNumbering is now only used to allocate suspend ids for generators.

BUG=v8:6921

Change-Id: I103e8593c94ef5b2e56c34ef4f77bd6e7d64796f
Reviewed-on: https://chromium-review.googlesource.com/722959
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48757}
2017-10-19 16:17:14 +00:00
Jakob Kummerow
e34debaf2b [bigint] Support BigInts in -,~,++,-- unary ops
and add the implementations for BitwiseNot, Increment, Decrement.
This CL teaches the respective bytecode handlers about BigInts,
and collects kBigInt type feedback for them (which TF discards
for now, substituting "any").

Bug: v8:6791
Change-Id: I4e802b301b9702d8270bda400edd7e885e6b11b9
Reviewed-on: https://chromium-review.googlesource.com/706101
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48479}
2017-10-12 01:40:33 +00:00
Adam Klein
bf55951cdd [bigint] Output ToNumber bytecode for unary plus
As part of that change, make ToNumber return in the accumulator.

Bug: v8:6791
Change-Id: I8ce0f4fbc7ad8ee7fb4a32a8a499394395010750
Reviewed-on: https://chromium-review.googlesource.com/658082
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47976}
2017-09-12 15:27:21 +00:00
Jakob Kummerow
cfcdeab002 [storeic] Drop duplicate stubs for each LanguageMode
Only the error cases of overwriting readonly properties need the
language_mode to decide whether to throw or be silent. Reading it
from the feedback vector's metadata (just like the C++ code in
ic.cc does) removes the need to duplicate each stub for each
language_mode ("StoreIC" + "StoreICStrict" etc.).

Change-Id: Ic0c67f9d40ca36c65e41b4f162b2ab70d155e549
Reviewed-on: https://chromium-review.googlesource.com/647373
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47836}
2017-09-05 18:00:39 +00:00
Leszek Swirski
37680d6563 [objects] Make feedback vector a first-class object
Instead of having feedback vector as a subtype of FixedArray with
reserved slots, make it a first-class variable-sized object with a
fixed-size header. This allows us to compress counters to ints in the
header, rather than forcing them to be Smis.

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Icc5f088ffbc2e2651b845bc71ea42060639e3e48
Reviewed-on: https://chromium-review.googlesource.com/585129
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46935}
2017-07-27 13:31:55 +00:00
Leszek Swirski
661726dd39 [runtime] Move profiler ticks from SFI to feedback vector (reland)
Reland of https://chromium-review.googlesource.com/c/544888/.

Instead of counting profiler ticks on the shared function info (which is
shared between native contexts), count them on the feedback vector
(which is not). This allows us to continue pushing optimization
decisions off the SFI, onto the feedback vector.

Note that a side-effect of this is that ICs don't have to walk the stack
to reset profiler ticks, as they can access the feedback vector directly
from their feedback nexus.

Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48
Reviewed-on: https://chromium-review.googlesource.com/579051
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46868}
2017-07-25 11:54:21 +00:00
Leszek Swirski
14c5c4fde7 Revert "[runtime] Move profiler ticks from SFI to feedback vector"
This reverts commit a2fcdc7cc8.

Reason for revert: Large regressions in RCS (https://chromeperf.appspot.com/group_report?bug_id=740126)

Original change's description:
> [runtime] Move profiler ticks from SFI to feedback vector
> 
> Instead of counting profiler ticks on the shared function info (which is
> shared between native contexts), count them on the feedback vector
> (which is not). This allows us to continue pushing optimization
> decisions off the SFI, onto the feedback vector.
> 
> Note that a side-effect of this is that ICs don't have to walk the stack
> to reset profiler ticks, as they can access the feedback vector directly
> from their feedback nexus.
> 
> Change-Id: I232ae9e759fca75cd89d393148a4ff42caa2646f
> Reviewed-on: https://chromium-review.googlesource.com/544888
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46411}

TBR=rmcilroy@chromium.org,leszeks@chromium.org,ishell@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Change-Id: Id587e4172e300c420f93c49744a2a0e66696edf8
Reviewed-on: https://chromium-review.googlesource.com/574227
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46702}
2017-07-17 11:51:32 +00:00
Alexey Kozyatinskiy
0896586083 [inspector] improve return position of explicit return in non-async function
Goal of this CL: explicit return from non-async function has position after
return expression as return position (will unblock [1]).

BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods.
If one of these methods is called then next generated bytecode will get passed
position. It's general treatment for most cases.
Unfortunately it doesn't work for Returns:
- debugger requires source positions exactly on kReturn bytecode in stepping
  implementation,
- BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn
  generates more then one bytecode and general solution will put return position
  on first generated bytecode,
- it's not easy to split BuildReturn function into two parts to allow something
  like following in BytecodeGenerator::VisitReturnStatement since generated
  bytecodes are actually controlled by execution_control().
..->BuildReturnPrologue();
..->SetReturnPosition(stmt);
..->Return();

In this CL we pass ReturnStatement through ExecutionControl and use it for
position when we emit return bytecode right here.

So this CL only will improve return position for returns inside of non-async
functions, I'll address async functions later.

[1] https://chromium-review.googlesource.com/c/543161/

Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db
Reviewed-on: https://chromium-review.googlesource.com/560738
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 19:10:13 +00:00
Camillo Bruni
36421dc467 [literals] Disable double lazy boilerplate for literals containing Arrays
By creating the boilerplate only on the second instantiation we cannot
propagate back the elements transitions early enough. The resulting literals
would change the initial ElementsKind one step too late and already pollute
ICs that went to monomorphic state.

- Disable lazy AllocationSites for literals containing arrays
- Introduce new ComplexLiteral class to share code between ObjectLiteral
  and ArrayLiteral
- RegexpLiteral now no longer needs a depth_ field

Bug: v8:6517, v8:6519, v8:6211
Change-Id: Ia88d1878954e8895c3d00a7dda8d71e95bba005c
Reviewed-on: https://chromium-review.googlesource.com/563305
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46603}
2017-07-12 19:11:04 +00:00
Leszek Swirski
a2fcdc7cc8 [runtime] Move profiler ticks from SFI to feedback vector
Instead of counting profiler ticks on the shared function info (which is
shared between native contexts), count them on the feedback vector
(which is not). This allows us to continue pushing optimization
decisions off the SFI, onto the feedback vector.

Note that a side-effect of this is that ICs don't have to walk the stack
to reset profiler ticks, as they can access the feedback vector directly
from their feedback nexus.

Change-Id: I232ae9e759fca75cd89d393148a4ff42caa2646f
Reviewed-on: https://chromium-review.googlesource.com/544888
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46411}
2017-07-05 12:04:50 +00:00
Camillo Bruni
015edc60ff [runtime] Don't store object literal boilerplates on first run
Storing the boilerplate on the first run leads to memory ovehead for code
that is run only once. Hence we directly return the creating literal on the
first run and only start creating copies from the second run on.

Bug: v8:6211
Change-Id: I69b96d124a5b594b991fdbcc76dbf935d973ffad
Reviewed-on: https://chromium-review.googlesource.com/530688
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45975}
2017-06-16 10:43:19 +00:00
Camillo Bruni
e822488d76 [runtime] Directly support double values in CloneShallowObjectLiteral
Bug: v8:6211
Change-Id: If6d2ef7889ae6a0c3aa430d3f69c53f19cc1f1c6
Reviewed-on: https://chromium-review.googlesource.com/509571
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45563}
2017-05-29 13:27:17 +00:00
Ross McIlroy
11a211ff1b Reland: [TypeFeedbackVector] Store optimized code in the vector
Since the feedback vector is itself a native context structure, why
not store optimized code for a function in there rather than in
a map from native context to code? This allows us to get rid of
the optimized code map in the SharedFunctionInfo, saving a pointer,
and making lookup of any optimized code quicker.

Original patch by Michael Stanton <mvstanton@chromium.org>

BUG=v8:6246,chromium:718891
TBR=yangguo@chromium.org,ulan@chromium.org

Change-Id: I3bb9ec0cfff32e667cca0e1403f964f33a6958a6
Reviewed-on: https://chromium-review.googlesource.com/500134
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45234}
2017-05-10 15:04:35 +00:00
Ross McIlroy
fd749344bf Revert "Reland: [TypeFeedbackVector] Store optimized code in the vector"
This reverts commit 662aa425ba.

Reason for revert: Crashing on Canary
BUG=chromium:718891

Original change's description:
> Reland: [TypeFeedbackVector] Store optimized code in the vector
> 
> Since the feedback vector is itself a native context structure, why
> not store optimized code for a function in there rather than in
> a map from native context to code? This allows us to get rid of
> the optimized code map in the SharedFunctionInfo, saving a pointer,
> and making lookup of any optimized code quicker.
> 
> Original patch by Michael Stanton <mvstanton@chromium.org>
> 
> BUG=v8:6246
> TBR=yangguo@chromium.org,ulan@chromium.org
> 
> Change-Id: Ic83e4011148164ef080c63215a0c77f1dfb7f327
> Reviewed-on: https://chromium-review.googlesource.com/494487
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45084}

TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org,jarin@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
BUG=v8:6246

Change-Id: Idab648d6fe260862c2a0e35366df19dcecf13a82
Reviewed-on: https://chromium-review.googlesource.com/498633
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45174}
2017-05-08 20:57:30 +00:00
Ross McIlroy
662aa425ba Reland: [TypeFeedbackVector] Store optimized code in the vector
Since the feedback vector is itself a native context structure, why
not store optimized code for a function in there rather than in
a map from native context to code? This allows us to get rid of
the optimized code map in the SharedFunctionInfo, saving a pointer,
and making lookup of any optimized code quicker.

Original patch by Michael Stanton <mvstanton@chromium.org>

BUG=v8:6246
TBR=yangguo@chromium.org,ulan@chromium.org

Change-Id: Ic83e4011148164ef080c63215a0c77f1dfb7f327
Reviewed-on: https://chromium-review.googlesource.com/494487
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45084}
2017-05-04 11:21:59 +00:00
Ross McIlroy
0f7356e64e [Interpreter] Only materialize output register if in a different equivalence set.
We only need to materialize the existing output register for a given
register transfer if it is in a different equivalence set, otherwise we
already have the value we want in the output register.

BUG=v8:4280

Change-Id: Ic4966590ac10445180aff353940d2c93e6a818aa
Reviewed-on: https://chromium-review.googlesource.com/493168
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45051}
2017-05-03 09:23:40 +00:00
Michael Achenbach
5fcf508e07 Revert "[TypeFeedbackVector] Store optimized code in the vector"
This reverts commit c5ad9c6d8e.

Reason for revert: Fails on gc stress:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/12661

Original change's description:
> [TypeFeedbackVector] Store optimized code in the vector
> 
> Since the feedback vector is itself a native context structure, why
> not store optimized code for a function in there rather than in
> a map from native context to code? This allows us to get rid of
> the optimized code map in the SharedFunctionInfo, saving a pointer,
> and making lookup of any optimized code quicker.
> 
> Original patch by Michael Stanton <mvstanton@chromium.org>
> 
> BUG=v8:6246
> 
> Change-Id: I60ff8c408c3001bc272b4b198c9cbaea2872a9e5
> Reviewed-on: https://chromium-review.googlesource.com/476891
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Michael Stanton <mvstanton@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45022}

TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org,mvstanton@chromium.org,jarin@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:6246

Change-Id: I9cd5735b03898cae6ae7adea0f19d32fceb31619
Reviewed-on: https://chromium-review.googlesource.com/493287
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45027}
2017-05-02 11:51:01 +00:00
Ross McIlroy
c5ad9c6d8e [TypeFeedbackVector] Store optimized code in the vector
Since the feedback vector is itself a native context structure, why
not store optimized code for a function in there rather than in
a map from native context to code? This allows us to get rid of
the optimized code map in the SharedFunctionInfo, saving a pointer,
and making lookup of any optimized code quicker.

Original patch by Michael Stanton <mvstanton@chromium.org>

BUG=v8:6246

Change-Id: I60ff8c408c3001bc272b4b198c9cbaea2872a9e5
Reviewed-on: https://chromium-review.googlesource.com/476891
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45022}
2017-05-02 11:20:23 +00:00
cbruni
3f73fecb13 [runtime] Ensure slow properties for simple {__proto__:null} literals.
With this CL we reduce the difference between directly using a null prototype
in a literal or using Object.create(null).
- The EmitFastCloneShallowObject builtin now supports cloning slow
  object boilerplates.
- Unified behavior to find the matching Map and instantiating it for
  Object.create(null) and literals with a null prototype.
- Cleanup of literal type parameter of CompileTimeValue, now in sync with
  ObjectLiteral flags.

Review-Url: https://codereview.chromium.org/2445333002
Cr-Commit-Position: refs/heads/master@{#44941}
2017-04-27 14:48:32 +00:00
yangguo
7b4e4ab70f Do not use new struct type where unnecessary.
We can use TUPLE2 or TUPLE3 for structs that do not need special
handling by deoptimizer and compiler.

This frees up a few instance types, so that adding the next few
new structs will not cause ABI compatibility to break.

R=mstarzinger@chromium.org

Review-Url: https://codereview.chromium.org/2811183005
Cr-Commit-Position: refs/heads/master@{#44685}
2017-04-18 12:46:39 +00:00
bmeurer
dd7ce93ce0 [turbofan] Collect and use type feedback on ToNumber.
Make Ignition collect BinaryOperationFeedback on ToNumber, using the
shared type feedback slot with the following Inc/Dec bytecode, and use
this feedback in TurboFan to turn the ToNumber(x) operation into a
SpeculativeNumberMultiply(x,1) with the feedback hint.

R=jarin@chromium.org, mstarzinger@chromium.org, rmcilroy@chromium.org
BUG=v8:6214,v8:5267

Review-Url: https://codereview.chromium.org/2804813003
Cr-Commit-Position: refs/heads/master@{#44440}
2017-04-06 11:54:44 +00:00
mvstanton
93f05b64ae [TypeFeedbackVector] Combine the literals array and the feedback vector.
They have the same lifetime. It's a match!

Both structures are native context dependent and dealt with (creation,
clearing, gathering feedback) at the same time. By treating the spaces used
for literal boilerplates as feedback vector slots, we no longer have to keep
track of the materialized literal count elsewhere.

A follow-on CL removes even more parser infrastructure related to this count.

BUG=v8:5456

Review-Url: https://codereview.chromium.org/2655853010
Cr-Commit-Position: refs/heads/master@{#42771}
2017-01-30 12:31:35 +00:00
leszeks
03a2b3a1a3 [ignition] Expect 'I' for signed bytecode operands
Because it was confusing seeing U8(negative value).

Review-Url: https://codereview.chromium.org/2640273002
Cr-Commit-Position: refs/heads/master@{#42662}
2017-01-25 17:39:24 +00:00
mvstanton
38602f1ff5 [FeedbackVector] Infrastructure for literal arrays in the vector.
This changes the NewClosure interface descriptor, but ignores
the additional vector/slot arguments for now. The feedback vector
gets larger, as it holds a space for each literal array. A follow-on
CL will constructively use this space.

BUG=v8:5456

Review-Url: https://codereview.chromium.org/2614373002
Cr-Commit-Position: refs/heads/master@{#42146}
2017-01-09 15:31:00 +00:00
hablich
aa8a208a47 Revert of [TypeFeedbackVector] Root literal arrays in function literals slots (patchset #11 id:370001 of https://codereview.chromium.org/2504153002/ )
Reason for revert:
Speculative revert because of blocked roll: https://codereview.chromium.org/2596013002/

Original issue's description:
> [TypeFeedbackVector] Root literal arrays in function literals slots
>
> Literal arrays and feedback vectors for a function can be garbage
> collected if we don't have a rooted closure for the function, which
> happens often. It's expensive to come back from this (recreating
> boilerplates and gathering feedback again), and the cost is
> disproportionate if the function was inlined into optimized code.
>
> To guard against losing these arrays when we need them, we'll now
> create literal arrays when creating the feedback vector for the outer
> closure, and root them strongly in that vector.
>
> BUG=v8:5456
>
> Review-Url: https://codereview.chromium.org/2504153002
> Cr-Commit-Position: refs/heads/master@{#41893}
> Committed: 93df094081

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

Review-Url: https://codereview.chromium.org/2597163002
Cr-Commit-Position: refs/heads/master@{#41917}
2016-12-22 10:26:36 +00:00
mvstanton
93df094081 [TypeFeedbackVector] Root literal arrays in function literals slots
Literal arrays and feedback vectors for a function can be garbage
collected if we don't have a rooted closure for the function, which
happens often. It's expensive to come back from this (recreating
boilerplates and gathering feedback again), and the cost is
disproportionate if the function was inlined into optimized code.

To guard against losing these arrays when we need them, we'll now
create literal arrays when creating the feedback vector for the outer
closure, and root them strongly in that vector.

BUG=v8:5456

Review-Url: https://codereview.chromium.org/2504153002
Cr-Commit-Position: refs/heads/master@{#41893}
2016-12-21 14:06:29 +00:00
mstarzinger
92b370ee64 Introduce {ConstantElementsPair} struct for type safety.
This introduces an explicit struct for the communication channel between
the {ArrayLiteral} AST node and the corresponding runtime methods. Those
methods take a pair of {ElementsKind} as well as an array (can either be
a FixedArray or a FixedDoubleArray) of constant values.

For bonus points it also reduces the size of the involved heap object by
one word (i.e. length field of FixedArray not needed anymore).

R=mvstanton@chromium.org

Review-Url: https://codereview.chromium.org/2581683003
Cr-Commit-Position: refs/heads/master@{#41752}
2016-12-16 10:57:06 +00:00
rmcilroy
ba5885cc8b [Interpreter] Ensure ValueOf is only called once for post-increment operations.
BUG=chromium:662418

Review-Url: https://codereview.chromium.org/2473223004
Cr-Commit-Position: refs/heads/master@{#40846}
2016-11-08 17:03:16 +00:00
leszeks
d2caa302a7 [ignition] Add bytecodes for loads/stores in the current context
The majority of context slot accesses are to the local context (current context
register and depth 0), so this adds bytecodes to optimise for that case.

This cuts down bytecode size by roughly 1% (measured on Octane and Top25).

Review-Url: https://codereview.chromium.org/2459513002
Cr-Commit-Position: refs/heads/master@{#40641}
2016-10-28 10:11:06 +00:00
neis
99cfa5f620 [interpreter] Remove redundant flag from bytecode cctest suite.
This removes the execute_ flag, which was always the negation of top_level_.

R=rmcilroy@chromium.org
BUG=

Review-Url: https://codereview.chromium.org/2390163003
Cr-Commit-Position: refs/heads/master@{#39961}
2016-10-04 16:30:15 +00:00
klaasb
5deb0bc157 [interpreter] Inline FastCloneShallowArrayStub into bytecode handler
The CreateArrayLiteral bytecode handler now directly inlines the FastCloneShallowArrayStub.

BUG=v8:4280

Review-Url: https://codereview.chromium.org/2341743003
Cr-Commit-Position: refs/heads/master@{#39562}
2016-09-20 18:04:50 +00:00
bmeurer
c7d7ca361d [turbofan] Collect invocation counts and compute relative call frequencies.
Add a notion of "invocation count" to the baseline compilers, which
increment a special slot in the TypeFeedbackVector for each invocation
of a given function (the optimized code doesn't currently collect this
information).

Use this invocation count to relativize the call counts on the call
sites within the function, so that the inlining heuristic has a view
of relative importance of a call site rather than some absolute numbers
with unclear meaning for the current function. Also apply the call site
frequency as a factor to all frequencies in the inlinee by passing this
to the graph builders so that the importance of a call site in an
inlinee is relative to the topmost optimized function.

Note that all functions that neither have literals nor need type
feedback slots will share a single invocation count cell in the
canonical empty type feedback vector, so their invocation count is
meaningless, but that doesn't matter since we only use the invocation
count to relativize call counts within the function, which we only have
if we have at least one type feedback vector (the CallIC slot).

See the design document for additional details on this change:
https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8

BUG=v8:5267,v8:5372
R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org

Review-Url: https://codereview.chromium.org/2337123003
Cr-Commit-Position: refs/heads/master@{#39410}
2016-09-14 10:20:48 +00:00
leszeks
1c0c5fda26 [Interpreter] Move context chain search loop to handler
Moves the context chain search loop out of generated bytecode, and into
the (Lda|Ldr|Sda)ContextSlot handler, by passing the context depth in as
an additional operand. This should decrease the bytecode size and
increase performance for deep context chain searches, at the cost of
slightly increasing bytecode size for shallow context access.

Review-Url: https://codereview.chromium.org/2336643002
Cr-Commit-Position: refs/heads/master@{#39378}
2016-09-13 11:09:33 +00:00
mythria
119f311245 [Interpreter] Enable allocation site mementos in CreateArrayLiterals.
In ignition, allocation site mementos were disabled when creating array
literals. Enabled them in this cl.

BUG=v8:4280
LOG=N

Review-Url: https://codereview.chromium.org/2294913006
Cr-Commit-Position: refs/heads/master@{#39234}
2016-09-07 09:06:17 +00:00
leszeks
b28b7e1328 [Interpreter] Remove constant pool type in tests
For historical reasons, the interpreter's bytecode expectations tests
required a type for the constant pool. This had two disadvantages:

 1. Strings and numbers were not visible in mixed pools, and
 2. Mismatches of pool types (e.g. when rebaselining) would cause parser
    errors

This removes the pool types, making everything 'mixed', but appending
the values to string and number valued constants. Specifying a pool type
in the *.golden header now prints a warning (for backwards compatibility).

BUG=v8:5350

Review-Url: https://codereview.chromium.org/2310103002
Cr-Commit-Position: refs/heads/master@{#39216}
2016-09-06 16:11:23 +00:00
klaasb
6c9ef89540 [interpreter] Add register output to ObjectLiteral
Avoids the always generated Star bytecodes after ObjectLiteral.

BUG=v4:4820
LOG=n

Review-Url: https://codereview.chromium.org/2216023003
Cr-Commit-Position: refs/heads/master@{#38480}
2016-08-09 10:30:29 +00:00
mythria
9e3e2ee2dd [Interpreter] Assign feedback slots for binary operations and use them in ignition.
Assign feedback slots in the type feedback vector for binary operations.
Update bytecode-generator to use these slots and add them as an operand
to binary operations.

BUG=v8:4280
LOG=N

Review-Url: https://codereview.chromium.org/2209633002
Cr-Commit-Position: refs/heads/master@{#38408}
2016-08-08 01:16:40 +00:00
klaasb
8097eeb9f2 [interpreter] Add CreateFunctionContext bytecode
Add a new bytecode to create a function context. The handler inlines
FastNewFunctionContextStub.

BUG=v8:4280
LOG=n

Review-Url: https://codereview.chromium.org/2187523002
Cr-Commit-Position: refs/heads/master@{#38301}
2016-08-03 14:43:26 +00:00
klaasb
220284638e [interpreter] Add a register operand to ToNumber
ToNumber's result is always directly stored to a register using a Star
bytecode. Fuse it into ToNumber.

BUG=v8:4280
LOG=n

Review-Url: https://codereview.chromium.org/2165953002
Cr-Commit-Position: refs/heads/master@{#37976}
2016-07-22 10:26:12 +00:00
rmcilroy
02c3414d62 [Interpereter] Inline FastNewClosure into CreateClosure bytecode handler
BUG=v8:4280

Review-Url: https://codereview.chromium.org/2113613002
Cr-Commit-Position: refs/heads/master@{#37453}
2016-06-30 15:32:59 +00:00
oth
769d332619 [interpreter] Filter expression positions at source.
With this change the bytecode array builder only emits expression
positions for bytecodes that can throw. This allows more peephole
optimization opportunities and results in smaller code.

BUG=v8:4280,chromium:615979
LOG=N

Review-Url: https://codereview.chromium.org/2038323002
Cr-Commit-Position: refs/heads/master@{#36863}
2016-06-09 13:33:29 +00:00
oth
5e8f8d4e8c [interpreter] Bytecode register optimizer.
Online optimization stage for reducing redundant transfers between registers.

BUG=V8:4280
LOG=N

Review-Url: https://codereview.chromium.org/1997653002
Cr-Commit-Position: refs/heads/master@{#36551}
2016-05-27 15:59:16 +00:00
oth
31c77b13df [interpreter] Address naming inconsistencies in bytecodes.
BUG=v8:4280
LOG=N

Review-Url: https://codereview.chromium.org/2007023003
Cr-Commit-Position: refs/heads/master@{#36509}
2016-05-25 10:47:29 +00:00
oth
e43fbde72b [Interpreter] Preserve source positions in peephole optimizer.
The original peephole optimizer logic in the BytecodeArrayBuilder did
not respect source positions as it was written before there were
bytecode source positions. This led to some minor differences to
FCG and was problematic when combined with pending bytecode
optimizations. This change makes the new peephole optimizer fully
respect source positions.

BUG=v8:4280
LOG=N

Review-Url: https://codereview.chromium.org/1998203002
Cr-Commit-Position: refs/heads/master@{#36439}
2016-05-23 13:33:20 +00:00
oth
52600c6b1c [interpreter] Add checks for source position to test-bytecode-generator.
Prints source position information alongside bytecode.

BUG=v8:4280
LOG=N

Review-Url: https://codereview.chromium.org/1963663002
Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:22:17 +00:00
rmcilroy
ac2a17abcb [Interpreter] Use FastCloneShallowObjectStub in CreateObjectLiteral bytecode.
Adapts FastCloneShallowObjectStub to enable it to be used by the
CreateObjectLiteral bytecode.

BUG=v8:4280
LOG=N

Review-Url: https://codereview.chromium.org/1922523002
Cr-Commit-Position: refs/heads/master@{#35909}
2016-04-29 14:21:33 +00:00
rmcilroy
c58f328581 [Interpreter] Introduce IncStub and DecStub.
Adds IncStub and DecStub TurboFan code stubs and hooks them up to the
interpreter's Inc and Dec bytecodes (which are used for count
operations, e.g. i++).

BUG=v8:4280
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#35720}
2016-04-22 10:36:33 +00:00
oth
48d082af38 [interpreter] Add support for scalable operands.
This change introduces wide prefix bytecodes to support wide (16-bit)
and extra-wide (32-bit) operands. It retires the previous
wide-bytecodes and reduces the number of operand types.

Operands are now either scalable or fixed size. Scalable operands
increase in width when a bytecode is prefixed with wide or extra-wide.

The bytecode handler table is extended to 256*3 entries. The
first 256 entries are used for bytecodes with 8-bit operands,
the second 256 entries are used for bytecodes with operands that
scale to 16-bits, and the third group of 256 entries are used for
bytecodes with operands that scale to 32-bits.

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

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

Cr-Commit-Position: refs/heads/master@{#34955}
2016-03-21 17:09:49 +00:00
verwaest
fd40570419 Don't do any special normalization if a boilerplate contains function literals.
This mechanism was used to ensure that functions ended up as constants on the map of prototypes defined using object literals, e.g.,:

function.prototype = {
  method: function() { ... }
}

Nowadays we treat prototypes specially, and make all their functions constants when an object turns prototype. Hence this special custom code isn't necessary anymore.

This also affects boilerplates that do not become prototypes. Their functions will not be constants but fields instead. Calling their methods will slow down. However, multiple instances of the same boilerplate will stay monomorphic. We'll have to see what the impact is for such objects, but preliminary benchmarks do not show this as an important regression.

BUG=chromium:593008
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#34602}
2016-03-08 22:13:49 +00:00
ssanfilippo
6ae030590d [Interpreter] Refactor bytecode generator test suite.
Bytecode expectations have been moved to external (.golden) files,
one per test. Each test in the suite builds a representation of the
the compiled bytecode using BytecodeExpectationsPrinter. The output is
then compared to the golden file. If the comparision fails, a textual
diff can be used to identify the discrepancies.

Only the test snippets are left in the cc file, which also allows to
make it more compact and meaningful. Leaving the snippets in the cc
file was a deliberate choice to allow keeping the "truth" about the
tests in the cc file, which will rarely change, as opposed to golden
files.

Golden files can be generated and kept up to date using
generate-bytecode-expectations, which also means that the test suite
can be batch updated whenever the bytecode or golden format changes.

The golden format has been slightly amended (no more comments about
`void*`, add size of the bytecode array) following the consideration
made while converting the tests.

There is also a fix: BytecodeExpectationsPrinter::top_level_ was left
uninitialized, leading to undefined behaviour.

BUG=v8:4280
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:19 +00:00