Commit Graph

55 Commits

Author SHA1 Message Date
Creddy
bb0975878f [runtime][parser] Use ArrayBoilerplateDescription all the way
* Rename BoilerplateDescription to ObjectBoilerplateDescription
* Add literal_type flag to ObjectBoilerplateDescription,
  which is stored as zeroth element of Fixed array
* Create ArrayBoilerplateDescription with elements_kind and
  constant_elements field
* Replace CompileTimeValue and ConstantElementPair with
  ArrayBoilerplateDescription
* Kill ConstantElementPair and CompileTimeValue

Change-Id: Icb42dcfd575a27e2b64ffd5e2e61f9d703d5e986
Bug: v8:7787, chromium:818642
Reviewed-on: https://chromium-review.googlesource.com/1122411
Commit-Queue: Chandan Reddy <chandanreddy@google.com>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54272}
2018-07-05 19:31:03 +00:00
Mythri
9461aa5619 [Interpreter] Enable sharing of load / store named property feedback
This cl enables sharing of feedback slots for load / sotre named property.
This is a follow up cl of
https://chromium-review.googlesource.com/c/v8/v8/+/966302 that introduces
this feature.

Bug: v8:7530
Change-Id: I0c056b7a3608117db2fc99ebcd6836dfeed471d8
Reviewed-on: https://chromium-review.googlesource.com/1065737
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53515}
2018-06-05 09:21:59 +00:00
Georg Neis
cf8cd1c444 [interpreter] Only create spread-related feedback slots when necessary.
Only create spread-related feedback slots when the array literal
actually contains a spread.

Bug: v8:5940
Change-Id: I0afad81d4bf1a86ebc1bf81f1213f680eb22bc49
Reviewed-on: https://chromium-review.googlesource.com/947955
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51721}
2018-03-05 11:01:32 +00:00
Georg Neis
2e2860f74f [ic] Introduce new IC for storing into array literals.
... and use it in the implementation of array literal spreads,
replacing calls to %AppendElement.

Array spreads in destructuring will be taken care of in a separate CL.

Bug: v8:5940, v8:7446
Change-Id: Idec52398902a7fd3c1244852cf73246f142404f0
Reviewed-on: https://chromium-review.googlesource.com/915364
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51709}
2018-03-02 21:12:57 +00:00
Camillo Bruni
1f307ba52f [runtime] Add BOILERPLATE_DESCRIPTION_TYPE InstanceType
Bug: v8:7266
Change-Id: I2835ec79aaa2821aca288685a3f230a7f8029186
Reviewed-on: https://chromium-review.googlesource.com/941948
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51696}
2018-03-02 13:43:27 +00:00
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
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
Benedikt Meurer
f1ec44e2f5 [turbofan] Optimize fast enum cache driven for..in.
This CL adds support to optimize for..in in fast enum-cache mode to the
same degree that it was optimized in Crankshaft, without adding the same
deoptimization loop that Crankshaft had with missing enum cache indices.
That means code like

  for (var k in o) {
    var v = o[k];
    // ...
  }

and code like

  for (var k in o) {
    if (Object.prototype.hasOwnProperty.call(o, k)) {
      var v = o[k];
      // ...
    }
  }

which follows the https://eslint.org/docs/rules/guard-for-in linter
rule, can now utilize the enum cache indices if o has only fast
properties on the receiver, which speeds up the access o[k]
significantly and reduces the pollution of the global megamorphic
stub cache.

For example the micro-benchmark in the tracking bug v8:6702 now runs
faster than ever before:

 forIn: 1516 ms.
 forInHasOwnProperty: 1674 ms.
 forInHasOwnPropertySafe: 1595 ms.
 forInSum: 2051 ms.
 forInSumSafe: 2215 ms.

Compared to numbers from V8 5.8 which is the last version running with
Crankshaft

 forIn: 1641 ms.
 forInHasOwnProperty: 1719 ms.
 forInHasOwnPropertySafe: 1802 ms.
 forInSum: 2226 ms.
 forInSumSafe: 2409 ms.

and V8 6.0 which is the current stable version with TurboFan:

 forIn: 1713 ms.
 forInHasOwnProperty: 5417 ms.
 forInHasOwnPropertySafe: 5324 ms.
 forInSum: 7556 ms.
 forInSumSafe: 11067 ms.

It also improves the throughput on the string-fasta benchmark by
around 7-10%, and there seems to be a ~5% improvement on the
Speedometer/React benchmark locally.

For this to work, the ForInPrepare bytecode was split into
ForInEnumerate and ForInPrepare, which is very similar to how it was
handled in Fullcodegen initially. In TurboFan we introduce a new
operator LoadFieldByIndex that does the dynamic property load.

This also removes the CheckMapValue operator again in favor of
just using LoadField, ReferenceEqual and CheckIf, which work
automatically with the EscapeAnalysis and the
BranchConditionElimination.

Bug: v8:6702
Change-Id: I91235413eea478ba77ace7bd14bb2f62e155dd9a
Reviewed-on: https://chromium-review.googlesource.com/645949
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47768}
2017-09-01 11:27:37 +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
Alexey Kozyatinskiy
a8176a530c [ignition] removed nop bytecode
Nop bytecodes are required only for break locations in debugger. Since nop bytecode doesn't change program state we can remove all of them.

There are at least two changes which this CL produce:
- we don't provide break position when we load local variable (still provide when load variable from global),
- we don't provide break position for statements without actual break positions (e.g. "a;") - these expressions should be super rare and user always can set breakpoint before or after this statement.

More details in one pager: https://docs.google.com/a/google.com/document/d/1JXlQpfMa9vRojbE272b6GMBbrfh6m_00135iAUOJEz8/edit?usp=sharing

Bug: v8:6425
Change-Id: I4aee73d497a84f7b5d89caa6dda6d3060567dfda
Reviewed-on: https://chromium-review.googlesource.com/543161
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46742}
2017-07-18 16:14:29 +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
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
Ross McIlroy
f3e4b7c14d [Interpreter] Move non-effectful accumulator load elision to BytecodeArrayWriter
Moves the logic for eliding non-effectful accumulator load elision from the
peephole optimizer to the BytecodeArrayWriter.

BUG=v8:6194

Change-Id: I05fbe4ee8ac340e5c355285d0b47e4a9d52fd0a8
Reviewed-on: https://chromium-review.googlesource.com/469828
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44560}
2017-04-11 11:26:59 +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
leszeks
e56437b630 [ignition] Use absolute values for jump offsets
Since JumpLoop is always backwards, and other jumps are always forwards,
we can store the jump offset as an always positive integer and decide on
the jump direction based on the bytecode. This will save a small amount
of space for large-ish for loops (>128 bytecodes).

Review-Url: https://codereview.chromium.org/2641443002
Cr-Commit-Position: refs/heads/master@{#42638}
2017-01-24 22:09:02 +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
ed35983ab7 [Interpreter] Remove Ldr[Named/Keyed]Property bytecodes and use Star Lookahead instead.
The Ldr[Named/Keyed]Property bytecodes are problematic for the deoptimizer when
inlining accessors in TurboFan. Remove them and replace with a Star lookahead
in the bytecode handlers for Lda[Named/Keyed]Property.

BUG=v8:4280

Review-Url: https://codereview.chromium.org/2485383002
Cr-Commit-Position: refs/heads/master@{#40860}
2016-11-09 13:16:37 +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
rmcilroy
27fe988b85 [Interpreter] Replace BytecodeRegisterAllocator with a simple bump pointer.
There are only a few occasions where we allocate a register in an outer
expression allocation scope, which makes the costly free-list approach
of the BytecodeRegisterAllocator unecessary. This CL replaces all
occurrences with moves to the accumulator and stores to a register
allocated in the correct scope. By doing this, we can simplify the
BytecodeRegisterAllocator to be a simple bump-pointer allocator
with registers released in the same order as allocated.

The following changes are also made:
 - Make BytecodeRegisterOptimizer able to use registers which have been
   unallocated, but not yet reused
 - Remove RegisterExpressionResultScope and rename
   AccumulatorExpressionResultScope to ValueExpressionResultScope
 - Introduce RegisterList to represent consecutive register
   allocations, and use this for operands to call bytecodes.

By avoiding the free-list handling, this gives another couple of
percent on CodeLoad.

BUG=v8:4280

Review-Url: https://codereview.chromium.org/2369873002
Cr-Commit-Position: refs/heads/master@{#39905}
2016-09-30 09:03:25 +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
mstarzinger
c9864173f1 [interpreter] Merge {OsrPoll} with {Jump} bytecode.
This introduces a new {JumpLoop} bytecode to combine the OSR polling
mechanism modeled by {OsrPoll} with the actual {Jump} performing the
backwards branch. This reduces the overall size and also avoids one
additional dispatch. It also makes sure that OSR polling is only done
within real loops.

R=rmcilroy@chromium.org
BUG=v8:4764

Review-Url: https://codereview.chromium.org/2331033002
Cr-Commit-Position: refs/heads/master@{#39384}
2016-09-13 13:07:36 +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
epertoso
708f80d243 [interpreter] Make the comparison bytecode handlers collect type feedback.
BUG=v8:5273

Review-Url: https://codereview.chromium.org/2286273002
Cr-Commit-Position: refs/heads/master@{#39006}
2016-08-30 10:21:39 +00:00
bmeurer
1915762cc8 [turbofan] Remove special JSForInStep and JSForInDone.
These JavaScript operators were special hacks to ensure that we always
operate on Smis for the magic for-in index variable, but this never
really worked in the OSR case, because the OsrValue for the index
variable didn't have the proper information (that we have for the
JSForInPrepare in the non-OSR case).

Now that we have loop induction variable analysis and binary operation
hints, we can just use JSLessThan and JSAdd instead with appropriate
Smi hints, which handle the OSR case by inserting Smi checks (that are
always true). Thanks to OSR deconstruction and loop peeling these Smi
checks will be hoisted so they don't hurt the OSR case too much.

Drive-by-change: Rename the ForInDone bytecode to ForInContinue, since
we have to lower it to JSLessThan to get the loop induction variable
goodness.

R=epertoso@chromium.org
BUG=v8:5267

Review-Url: https://codereview.chromium.org/2289613002
Cr-Commit-Position: refs/heads/master@{#38968}
2016-08-29 08:47:33 +00:00
verwaest
5558a50878 Merge DeclarationScope::temps_ and Scope::ordered_variables_ into Scope::locals_
BUG=v8:5209

Review-Url: https://codereview.chromium.org/2272083003
Cr-Commit-Position: refs/heads/master@{#38920}
2016-08-25 19:12:00 +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
26c1755242 [interpreter] Put object in register for ToObject/ForInPrepare
This gets rid of the Star bytecodes that were always dispatched to from
ToObject.
ToObject now outputs to register instead of to the accumulator and
ForInPrepare gets the receiver object from an input register.

BUG=v8:4820
LOG=n

Review-Url: https://codereview.chromium.org/2189463006
Cr-Commit-Position: refs/heads/master@{#38177}
2016-07-29 11:18:06 +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
25b3fe7961 [interpreter] Introduce fused bytecodes for common sequences.
This change introduces five fused bytecodes for common bytecode
sequences on popular websites. These are LdrNamedProperty,
LdrKeyedProperty, LdrGlobal, LdrContextSlot, and LdrUndefined. These
load values into a destination register operand instead of the
accumulator. They are emitted by the peephole optimizer.

BUG=v8:4280
LOG=N

Review-Url: https://codereview.chromium.org/1985753002
Cr-Commit-Position: refs/heads/master@{#36507}
2016-05-25 09:56:49 +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