Skip to content

V
V8
Switch branch/tag
  1. 29 Jun, 2015 1 commit
    • mtrofin's avatar
      [turbofan] Greedy allocator refactoring. · 1cd60451
      mtrofin authored 
      Separated core greedy allocator concepts, exposing the APIs we would want to continue working with. In particular, this change completely reworks CoalescedLiveRanges to reflect the fact that we expect more than one possible conflict, scrapping the initial design of the structure. Since this is a critical part of the design, this change may be thought of as a full rewrite of the algorithm.

Reduced all heuristics to just 2 essential ones: split "somewhere", which we'll still need when all other heuristics fail; and spill.

Introduced a simple primitive for splitting - at GapPosition::START. The goal is to use such primitives to quickly and reliably author heuristics.

I expected this primitive to "just work" for any arbitrary instruction index within a live range - e.g. its middle. That's not the case, it seems to upset execution in certain scenarios. Restricting to either before/after use positions seems to work. I'm still investigating what the source of failures is in the case of "arbitrary instruction in the range" case.

I intended to document the rationale and prove the soundness of always using START for splits, but I will postpone to after this last remaining issue is resolved.

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

Cr-Commit-Position: refs/heads/master@{#29352}
      1cd60451
  3. 26 Jun, 2015 2 commits
  5. 25 Jun, 2015 1 commit
  7. 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
  9. 17 Jun, 2015 1 commit
  11. 16 Jun, 2015 2 commits
  13. 12 Jun, 2015 1 commit
  15. 09 Jun, 2015 1 commit
  17. 03 Jun, 2015 2 commits
  19. 01 Jun, 2015 1 commit
    • bmeurer's avatar
      [turbofan] First step towards sanitizing for-in and making it optimizable. · e2e47f30
      bmeurer authored 
      In a nutshell: The FILTER_KEY builtin is gone, and was replaced by a
simple runtime call to ForInFilter, which does everything and is even
cheaper (because FILTER_KEY used to call into the runtime anyway).
And ForInFilter returns either the name or undefined, which makes it
possible to remove the control flow construction from the AstGraphBuilder,
and thereby make both the initialization and the per-loop code of for-in
optimizable later (in typed lowering).

R=jarin@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#28711}
      e2e47f30
  21. 29 May, 2015 1 commit
  23. 28 May, 2015 1 commit
  25. 22 May, 2015 3 commits
    • binji's avatar
      Implement SharedArrayBuffer. · aff8ebb0
      binji authored 
      This adds a new external type (v8::SharedArrayBuffer) that uses a JSArrayBuffer
under the hood. It can be distinguished from an ArrayBuffer by the newly-added
is_shared() bit.

Currently there is no difference in functionality between a SharedArrayBuffer
and an ArrayBuffer. However, a future CL will add the Atomics API, which is
only available on an SharedArrayBuffer. All non-atomic accesses are identical
to ArrayBuffer accesses.

LOG=N
BUG=

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

Cr-Commit-Position: refs/heads/master@{#28594}
      aff8ebb0
    • yangguo's avatar
      Revert of Implement SharedArrayBuffer (patchset #7 id:120001 of... · 57ee3c0f
      yangguo authored 
      Revert of Implement SharedArrayBuffer (patchset #7 id:120001 of https://codereview.chromium.org/1136553006/)

Reason for revert:
breaks build

Original issue's description:
> Implement SharedArrayBuffer.
>
> This adds a new external type (v8::SharedArrayBuffer) that uses a JSArrayBuffer under the hood. It can be distinguished from an ArrayBuffer by the newly-added is_shared() bit.
>
> Currently there is no difference in functionality between a SharedArrayBuffer and an ArrayBuffer. However, a future CL will add the Atomics API, which is only available on an SharedArrayBuffer. All non-atomic accesses are identical to ArrayBuffer accesses.
>
> BUG=
>
> Committed: https://crrev.com/57170bff7baf341c666252a7f6a49e9c08d51263
> Cr-Commit-Position: refs/heads/master@{#28588}

TBR=jarin@chromium.org,jochen@chromium.org,binji@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

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

Cr-Commit-Position: refs/heads/master@{#28589}
      57ee3c0f
    • binji's avatar
      Implement SharedArrayBuffer. · 57170bff
      binji authored 
      This adds a new external type (v8::SharedArrayBuffer) that uses a JSArrayBuffer under the hood. It can be distinguished from an ArrayBuffer by the newly-added is_shared() bit.

Currently there is no difference in functionality between a SharedArrayBuffer and an ArrayBuffer. However, a future CL will add the Atomics API, which is only available on an SharedArrayBuffer. All non-atomic accesses are identical to ArrayBuffer accesses.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#28588}
      57170bff
  27. 21 May, 2015 1 commit
  29. 20 May, 2015 2 commits
  31. 15 May, 2015 2 commits
  33. 11 May, 2015 2 commits
  35. 08 May, 2015 1 commit
    • domenic's avatar
      Re-land: Make V8 extras a separate type of native · 570fca61
      domenic authored 
      Instead of making them an extra option that gets passed in and compiled
at the end of the natives file for a given run of js2c, we now make them a
separate run of js2c with a separate natives file output.

This natives file output is then compiled in the bootstrapper. It is not part
of the snapshot (yet), but instead is treated similar to the experimental
natives, just without any of the complexity that comes from tieing the
behavior to flags. We also don't need counterparts to
InitializeExperimentalGlobal and InstallExperimentalNativeFunctions (yet?).

This fixes the issue with https://codereview.chromium.org/1129743003 by making
the dummy file that is generated for snapshots with no extras (or no experimental
features) nonempty.

R=yangguo@chromium.org, jochen@chromium.org
BUG=

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

Cr-Commit-Position: refs/heads/master@{#28311}
      570fca61
  37. 07 May, 2015 2 commits
    • domenic's avatar
      Revert of Make V8 extras a separate type of native (patchset #4 id:60001 of... · 010c515d
      domenic authored 
      Revert of Make V8 extras a separate type of native (patchset #4 id:60001 of https://codereview.chromium.org/1129743003/)

Reason for revert:
https://build.chromium.org/p/client.v8/builders/V8-Blink%20Linux%2064%20%28dbg%29/builds/2745

Original issue's description:
> Make V8 extras a separate type of native
>
> Instead of making them an extra option that gets passed in and compiled
> at the end of the natives file for a given run of js2c, we now make them a
> separate run of js2c with a separate natives file output.
>
> This natives file output is then compiled in the bootstrapper. It is not part
> of the snapshot (yet), but instead is treated similar to the experimental
> natives, just without any of the complexity that comes from tieing the
> behavior to flags. We also don't add counterparts to
> InitializeExperimentalGlobal and InstallExperimentalNativeFunctions, yet.
>
> R=yangguo@chromium.org, jochen@chromium.org
> BUG=
>
> Committed: https://crrev.com/c93aff4ac63ad9ffb6318e750335208de32b7902
> Cr-Commit-Position: refs/heads/master@{#28296}

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

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

Cr-Commit-Position: refs/heads/master@{#28299}
      010c515d
    • domenic's avatar
      Make V8 extras a separate type of native · c93aff4a
      domenic authored 
      Instead of making them an extra option that gets passed in and compiled
at the end of the natives file for a given run of js2c, we now make them a
separate run of js2c with a separate natives file output.

This natives file output is then compiled in the bootstrapper. It is not part
of the snapshot (yet), but instead is treated similar to the experimental
natives, just without any of the complexity that comes from tieing the
behavior to flags. We also don't add counterparts to
InitializeExperimentalGlobal and InstallExperimentalNativeFunctions, yet.

R=yangguo@chromium.org, jochen@chromium.org
BUG=

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

Cr-Commit-Position: refs/heads/master@{#28296}
      c93aff4a
  39. 06 May, 2015 3 commits
  41. 05 May, 2015 1 commit
    • bmeurer's avatar
      [turbofan] Fix tail call optimization. · d21de2a4
      bmeurer authored 
      Tail calls are matched on the graph, with a dedicated tail call
optimization that is actually testable. The instruction selection can
still fall back to a regular if the platform constraints don't allow to
emit a tail call (i.e. the return locations of caller and callee differ
or the callee takes non-register parameters, which is a restriction that
will be removed in the future).

Also explicitly limit tail call optimization to stubs for now and drop
the global flag.

BUG=v8:4076
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#28219}
      d21de2a4
  43. 04 May, 2015 1 commit
  45. 29 Apr, 2015 1 commit
  47. 28 Apr, 2015 1 commit
  49. 21 Apr, 2015 1 commit
  51. 20 Apr, 2015 2 commits
  53. 17 Apr, 2015 1 commit
  55. 16 Apr, 2015 1 commit