Skip to content

V
V8
Switch branch/tag
  1. 22 Jun, 2017 1 commit
  3. 20 Jun, 2017 1 commit
    • Peter Marshall's avatar
      [runtime] Port SpreadCall code to CSA. · a971a64d
      Peter Marshall authored 
      We can remove a lot of native code and rely on CallOrConstructVarargs
to do the stack manipulation for us.

This will also take advantage of the fast-path for double arrays in
CallOrConstructDoubleVarargs.

We can also remove Runtime_SpreadIterableFixed because it isn't used
anymore. We just call directly into spread_iterable from CSA.

Bug: v8:6488, chromium:704966
Change-Id: I81a18281f062619851134fff7ce88471566ee3b5
Reviewed-on: https://chromium-review.googlesource.com/535615Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46038}
      a971a64d
  5. 16 Jun, 2017 1 commit
  7. 08 Jun, 2017 1 commit
    • bmeurer's avatar
      [builtins] Start refactoring the Apply builtin. · af76779a
      bmeurer authored 
      This splits the monolithic Apply builtin into several smaller builtins,
namely CallVargargs and ConstructVarargs, which accept a length and a
FixedArray of elements and deal with the actual stack manipulation, and
CallWithArrayLike / ConstructWithArrayLike that deal with getting the
elements from the receiver (for Function.prototype.apply, Reflect.apply
and Reflect.construct), which can now be written using the CSA.

The idea is that these builtins can be reused by TurboFan directly in
the future when we optimize apply better, and that we can also reuse the
core logic in the handling of spread calls/constructs.

R=petermarshall@chromium.org
BUG=v8:4587,v8:5269

Review-Url: https://codereview.chromium.org/2930623002
Cr-Commit-Position: refs/heads/master@{#45794}
      af76779a
  9. 07 Jun, 2017 1 commit
  11. 18 May, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Avoid allocating rest parameters for spread calls. · bfa319e5
      bmeurer authored 
      We already had an optimization to turn Function.prototype.apply with
arguments object, i.e.

  function foo() { return bar.apply(this, arguments); }

into a special operator JSCallForwardVarargs, which avoids the
allocation and deconstruction of the arguments object, but just passes
along the incoming parameters. We can do the same for rest parameters
and spread calls/constructs, i.e.

  class A extends B {
    constructor(...args) { super(...args); }
  }

or

  function foo(...args) { return bar(1, 2, 3, ...args); }

where we basically pass along the parameters (plus maybe additional
statically known parameters).

For this, we introduce a new JSConstructForwardVarargs operator and
generalize the CallForwardVarargs builtins that are backing this.

BUG=v8:6407,v8:6278,v8:6344
R=jarin@chromium.org

Review-Url: https://codereview.chromium.org/2890023004
Cr-Commit-Position: refs/heads/master@{#45388}
      bfa319e5
  13. 21 Apr, 2017 5 commits
  15. 11 Apr, 2017 2 commits
  17. 10 Apr, 2017 1 commit
    • Leszek Swirski's avatar
      [ignition] Add call bytecodes for undefined receiver · 751e8935
      Leszek Swirski authored 
      Adds a collection of call bytecodes which have an implicit undefined
receiver argument, for cases such as global calls where we know that the
receiver has to be undefined. This way we can skip an LdaUndefined,
decrease bytecode register pressure, and set a more accurate
ConvertReceiverMode on the interpreter and TurboFan call.

As a side effect, the "normal" Call bytecode now becomes a rare case
(only with calls and super property calls), so we get rid of its 0-2
argument special cases and modify CallProperty[N] to use the
NotNullOrUndefined ConvertReceiverMode.

Change-Id: I9374a32fefd66fc0251b5193bae7a6b7dc31eefc
Reviewed-on: https://chromium-review.googlesource.com/463287
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44530}
      751e8935
  19. 07 Apr, 2017 1 commit
    • jgruber's avatar
      [builtins] Introduce new TFC macro and auto-generate TFS descriptors · 9ddfeafe
      jgruber authored 
      Split TFS builtins into

* TFC: TF builtins with stub linkage that use a custom interface descriptor
       (e.g. because of a non-standard return size or untagged arguments)
* TFS: the rest.

Automatically generate interface descriptors for TFS builtins to reduce
boilerplate involved in setting up stub calls. These are now as simple as
creating the TFS stub and using CSA::CallBuiltin, no extra work required.

BUG=v8:6116

Review-Url: https://codereview.chromium.org/2777203007
Cr-Commit-Position: refs/heads/master@{#44490}
      9ddfeafe
  21. 16 Mar, 2017 1 commit
    • jgruber's avatar
      [regexp] Port RegExpExecStub to CSA (mostly) · 5cc61896
      jgruber authored 
      This moves most of the logic contained in RegExpExecStub to CSA.  Benefits are
mostly easier readability and hackability, and removal of a large chunk of
platform-specific assembly.

Exit frame construction and the final call remain in RegExpExecStub.

BUG=v8:5339,v8:592

Review-Url: https://codereview.chromium.org/2738413002
Cr-Commit-Position: refs/heads/master@{#43844}
      5cc61896
  23. 28 Feb, 2017 1 commit
    • tebbi's avatar
      [turbofan] escape analysis supports arguments object and rest elements · 7467f16d
      tebbi authored 
      The new NewUnmappedArgumentsElements node now takes two inputs:
- the frame holding the arguments (current frame or arguments adaptor frame)
- the length of the suffix of passed arguments to be copied into the backing store

These inputs are computed with two new node types:
ArgumentsFrame()
ArgumentsLength[formal_parameter_count,is_rest_length](Node* arguments_frame)
The node type NewRestParameterElements can now be expressed with NewUnmappedArgumentsElements and an appropriate length and is thus not needed anymore.

In escape analysis, we lower loads from the length field of NewUnmappedArgumentsElements with its length input and if we find out that no write access to the arguments elements exists, we replace element loads with direct stack access and replace the NewUnmappedArgumentsElements node with a node of the new node type ArgumentsElementsState. This corresponds to an ObjectState node and gets translated into a deoptimizer instruction to allocate the backing store. Together with the already existing deoptimizer support for the actual arguments object/rest parameters, this allows to remove all allocations for arguments objects/rest parameters in this case.
In the deoptimizer, we read the actual parameters from the stack while transforming the static deopt info into TranslatedValue objects.

If escape analysis cannot remove the backing store allocation, NewUnmappedArgumentsElements gets lo

BUG=v8:5726

Review-Url: https://codereview.chromium.org/2692753004
Cr-Commit-Position: refs/heads/master@{#43475}
      7467f16d
  25. 16 Feb, 2017 1 commit
    • Daniel Clifford's avatar
      [ignition] Optimize reloading of registers before Dispatch · bd21c2bd
      Daniel Clifford authored 
      Before this patch, the registers needed for bytecode dispatch in interpreter
handlers were inconsistently stored in the interpreter frame and/or kept in
values that remained live across calls.

After this patch, these registers are explicitly reloaded after calls, making it
possible to elide the spills of those registers before the call in many cases.

Some highlights from the CL:

* Added methods to the CSA and InterpreterAssembler to efficiently store and
  load Smis values and Smi interpreter registers on x64 without explicit
  tagging/untagging.

* Created Variables for all of the interpreter-internal values that need to be
  reloaded before bytecode dispatch at the end of an interpreter handler.

* The bytecode offset can be written out early in a handler by marking it
  has having a call along it's critical path. By moving this early in a
  handler, it becomes possible to use memory operands for pushes used to
  marshall parameters when making calls.

Change-Id: Icf8d7798789f88a4489e06a7092616bbbb881577
Reviewed-on: https://chromium-review.googlesource.com/442566
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43260}
      bd21c2bd
  27. 07 Feb, 2017 1 commit
  29. 02 Feb, 2017 2 commits
  31. 27 Jan, 2017 1 commit
    • yangguo's avatar
      [liveedit] reimplement frame restarting. · 3f47c63d
      yangguo authored 
      Previously, when restarting a frame, we would rewrite all frames
between the debugger activation and the frame to restart to squash
them, and replace the return address with that of a builtin to
leave that rewritten frame, and restart the function by calling it.

We now simply remember the frame to drop to, and upon returning
from the debugger, we check whether to drop the frame, load the
new FP, and restart the function.

R=jgruber@chromium.org, mstarzinger@chromium.org
BUG=v8:5587

Review-Url: https://codereview.chromium.org/2636913002
Cr-Commit-Position: refs/heads/master@{#42725}
      3f47c63d
  33. 26 Jan, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Introduce JSCallForwardVarargs operator. · 69747e26
      bmeurer authored 
      We turn a JSCallFunction node for

  f.apply(receiver, arguments)

into a JSCallForwardVarargs node, when the arguments refers to the
arguments of the outermost optimized code object, i.e. not an inlined
arguments, and the apply method refers to Function.prototype.apply,
and there's no other user of arguments except in frame states.

We also replace the arguments node in the graph with a marker for
the Deoptimizer similar to Crankshaft to make sure we don't materialize
unused arguments just for the sake of deoptimization. We plan to replace
this with a saner EscapeAnalysis based solution soon.

R=jarin@chromium.org
BUG=v8:5267,v8:5726

Review-Url: https://codereview.chromium.org/2655233002
Cr-Commit-Position: refs/heads/master@{#42680}
      69747e26
  35. 29 Dec, 2016 1 commit
  37. 23 Dec, 2016 1 commit
  39. 22 Dec, 2016 2 commits
    • bmeurer's avatar
      [turbofan] Lower StringCharCodeAt to a dedicated builtin. · 86e2a199
      bmeurer authored 
      Introduce a dedicated StringCharCodeAt builtin, that performs the core
logic of String.prototype.charCodeAt and lower the StringCharCodeAt
simplified operator to a call to this builtin rather than inlining the
full functionality into each and every TurboFan graph using it. This can
significantly reduce compile time in some cases (i.e. can easily shave
off over 50% of compile time overhead for small functions that call
String.prototype.charCodeAt).

Currently it returns the char code as TaggedSigned value, but
middle-term we should make it possible to return untagged values
from builtins.

R=yangguo@chromium.org

Review-Url: https://codereview.chromium.org/2600443002
Cr-Commit-Position: refs/heads/master@{#41912}
      86e2a199
    • bmeurer's avatar
      [turbofan] Introduce a dedicated StringCharAt operator. · 05f5ebce
      bmeurer authored 
      Previously String element access and String.prototype.charAt were
lowered to a subgraph StringFromCharCode(StringCharCodeAt(s, k)),
however that can be fairly expensive both runtime and compile time
wise. The dedicated StringCharAt operator is implemented via a call
to a builtin that does exactly this.

R=yangguo@chromium.org

Review-Url: https://codereview.chromium.org/2599683002
Cr-Commit-Position: refs/heads/master@{#41909}
      05f5ebce
  41. 14 Dec, 2016 1 commit
  43. 08 Dec, 2016 1 commit
  45. 01 Dec, 2016 1 commit
  47. 29 Nov, 2016 1 commit
  49. 16 Nov, 2016 1 commit
  51. 15 Nov, 2016 1 commit
  53. 07 Nov, 2016 1 commit
  55. 12 Oct, 2016 2 commits
  57. 05 Oct, 2016 1 commit
  59. 29 Sep, 2016 1 commit
  61. 27 Sep, 2016 1 commit
  63. 22 Sep, 2016 1 commit