Skip to content

V
V8
Switch branch/tag
  1. 11 Jan, 2016 1 commit
  3. 16 Dec, 2015 2 commits
  5. 28 Oct, 2015 1 commit
    • mstarzinger's avatar
      [turbofan] Lower mapped arguments objects in inline frame. · d1f77302
      mstarzinger authored 
      This lowers JSCreateArguments nodes within inline (i.e. non-outermost)
frames that create "mapped arguments objects" to inline allocations.

The arguments count as well as each value is statically known and can be
directly stored into the arguments object. Note that the object is still
context-dependent and the map is loaded from the current context. The
object size is not taken into account for now, we might want to limit it
later though to keep code size bounded.

R=jarin@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#31619}
      d1f77302
  7. 20 Oct, 2015 1 commit
  9. 19 Oct, 2015 1 commit
  11. 16 Oct, 2015 2 commits
    • jarin's avatar
      Revert of [turbofan] Initial support for monomorphic/polymorphic property... · 5c534812
      jarin authored 
      Revert of [turbofan] Initial support for monomorphic/polymorphic property loads. (patchset #3 id:100001 of https://codereview.chromium.org/1396333010/ )

Reason for revert:
Waterfall redness.

Original issue's description:
> [turbofan] Initial support for monomorphic/polymorphic property loads.
>
> Native context specialization now lowers monomorphic and
> polymorphic accesses to data and constant data properties on
> object and/or prototype chain. We don't deal with accessors
> yet, and we also completely ignore proxies (which is compatible
> with what Crankshaft does).
>
> The code is more or less the straightforward implementation. We
> will need to refactor that and extract common patterns once the
> remaining bits for full load/store support is in.
>
> CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel
> R=jarin@chromium.org
> BUG=v8:4470
> LOG=n
>
> Committed: https://crrev.com/3a0bf860b7177f7abef01ff308a53603389d958e
> Cr-Commit-Position: refs/heads/master@{#31340}

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

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

Cr-Commit-Position: refs/heads/master@{#31341}
      5c534812
    • bmeurer's avatar
      [turbofan] Initial support for monomorphic/polymorphic property loads. · 3a0bf860
      bmeurer authored 
      Native context specialization now lowers monomorphic and
polymorphic accesses to data and constant data properties on
object and/or prototype chain. We don't deal with accessors
yet, and we also completely ignore proxies (which is compatible
with what Crankshaft does).

The code is more or less the straightforward implementation. We
will need to refactor that and extract common patterns once the
remaining bits for full load/store support is in.

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

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

Cr-Commit-Position: refs/heads/master@{#31340}
      3a0bf860
  13. 31 Aug, 2015 1 commit
    • mstarzinger's avatar
      [turbofan] Remove usage of Unique<T> from graph. · 6e65e6db
      mstarzinger authored 
      The usage of Unique<T> throughout the TurboFan IR does not have any
advantage. There is no single point in time when they are initialized
and most use-sites looked through to the underlying Handle<T> anyways.
Also there already was a mixture of Handle<T> versus Unique<T> in the
graph and this unifies the situation to use Handle<T> everywhere.

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

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

Cr-Commit-Position: refs/heads/master@{#30458}
      6e65e6db
  15. 23 Jun, 2015 1 commit
  17. 19 Jun, 2015 1 commit
    • bmeurer's avatar
      [turbofan] Proper dead code elimination as regular reducer. · 733a2463
      bmeurer authored 
      The three different concerns that the ControlReducer used to deal with
are now properly separated into

  a.) DeadCodeElimination, which is a regular AdvancedReducer, that
      propagates Dead via control edges,
  b.) CommonOperatorReducer, which does strength reduction on common
      operators (i.e. Branch, Phi, and friends), and
  c.) GraphTrimming, which removes dead->live edges from the graph.

This will make it possible to run the DeadCodeElimination together with
other passes that actually introduce Dead nodes, i.e. typed lowering;
and it opens the door for general inlining without two stage fix point
iteration.

To make the DeadCodeElimination easier and more uniform, we basically
reverted the introduction of DeadValue and DeadEffect, and changed the
Dead operator to produce control, value and effect. Note however that
this is not a requirement, but merely a way to make dead propagation
easier and more uniform. We could always go back and decide to have
different Dead operators if some other change requires that.

Note that there are several additional opportunities for cleanup now,
i.e. OSR deconstruction could be a regular reducer now, and we don't
need to use TheHole as dead value marker in the GraphReducer. And we can
actually run the dead code elimination together with the other passes
instead of using separate passes over the graph.  We will do this in
follow up CLs.

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

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

Cr-Commit-Position: refs/heads/master@{#29146}
      733a2463
  19. 18 Jun, 2015 1 commit
  21. 01 Jun, 2015 1 commit
  23. 27 May, 2015 1 commit
  25. 15 May, 2015 1 commit
  27. 24 Apr, 2015 1 commit
  29. 16 Apr, 2015 1 commit
  31. 09 Mar, 2015 1 commit
    • jarin's avatar
      [turbofan] Fix lazy deopt for JSToNumber conversions in binary operations. · 6f559b7e
      jarin authored 
      This slightly hacky change provides lazy deopt points for to-number conversions in binops: When we deopt from a to-number conversion, we create a frame state with the already-converted value(s) so that we do not repeat the side effect of the conversion.

Embenchen numbers are below. It is not quite clear what happened to fasta - the hot code looks nearly identical.

Current: EmbenchenBox2d(RunTime): 12746 ms.
d8-master: EmbenchenBox2d(RunTime): 13861 ms.
----------- bullet.js
Current: EmbenchenBullet(RunTime): 17680 ms.
d8-master: EmbenchenBullet(RunTime): 19170 ms.
----------- copy.js
Current: EmbenchenCopy(RunTime): 4939 ms.
d8-master: EmbenchenCopy(RunTime): 4943 ms.
----------- corrections.js
Current: EmbenchenCorrections(RunTime): 6639 ms.
d8-master: EmbenchenCorrections(RunTime): 6728 ms.
----------- fannkuch.js
Current: EmbenchenFannkuch(RunTime): 4630 ms.
d8-master: EmbenchenFannkuch(RunTime): 4872 ms.
----------- fasta.js
Current: EmbenchenFasta(RunTime): 10209 ms.
d8-master: EmbenchenFasta(RunTime): 9673 ms.
----------- lua_binarytrees.js
Current: EmbenchenLuaBinaryTrees(RunTime): 12936 ms.
d8-master: EmbenchenLuaBinaryTrees(RunTime): 15529 ms.
----------- memops.js
Current: EmbenchenMemOps(RunTime): 7357 ms.
d8-master: EmbenchenMemOps(RunTime): 7340 ms.
----------- primes.js
Current: EmbenchenPrimes(RunTime): 7530 ms.
d8-master: EmbenchenPrimes(RunTime): 7457 ms.
----------- skinning.js
Current: EmbenchenSkinning(RunTime): 15832 ms.
d8-master: EmbenchenSkinning(RunTime): 15630 ms.
----------- zlib.js
Current: EmbenchenZLib(RunTime): 11176 ms.
d8-master: EmbenchenZLib(RunTime): 11324 ms.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#27071}
      6f559b7e
  33. 16 Feb, 2015 1 commit
  35. 29 Jan, 2015 1 commit
  37. 21 Jan, 2015 1 commit
  39. 14 Jan, 2015 2 commits
  41. 08 Jan, 2015 1 commit
  43. 23 Dec, 2014 1 commit
  45. 07 Nov, 2014 1 commit
  47. 30 Oct, 2014 1 commit
  49. 15 Oct, 2014 2 commits
  51. 13 Oct, 2014 1 commit
  53. 07 Oct, 2014 1 commit
  55. 24 Sep, 2014 1 commit
  57. 10 Sep, 2014 1 commit
  59. 08 Sep, 2014 1 commit
  61. 04 Sep, 2014 2 commits
  63. 18 Aug, 2014 1 commit
  65. 30 Jul, 2014 1 commit