Skip to content

V
V8
Switch branch/tag
  1. 25 May, 2018 1 commit
  3. 07 May, 2018 1 commit
    • jgruber's avatar
      [builtins] Convert CEntry/GetProperty/StringAdd stubs to builtins · d8131cd6
      jgruber authored 
      Stubs and builtins are very similar. The main differences are that
stubs can be parameterized and may be generated at runtime, whereas
builtins are generated at mksnapshot-time and shipped with the snapshot
(or embedded into the binary).

My main motivation for these conversions is that we can generate
faster calls and jumps to (embedded) builtins callees from (embedded)
builtin callers. Instead of going through the builtins constants table
indirection, we can simply do a pc-relative call/jump.

This also unlocks other refactorings, e.g. removal of
CallRuntimeDelayed.

TBR=mlippautz@chromium.org

Bug: v8:6666
Change-Id: I4cd63477f19a330ec70bbf20e2af8a42fb05fabb
Reviewed-on: https://chromium-review.googlesource.com/1044245Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53027}
      d8131cd6
  5. 03 May, 2018 1 commit
  7. 22 Feb, 2018 1 commit
    • Benedikt Meurer's avatar
      [cleanup] Introduce a dedicated FeedbackCell. · aff1f378
      Benedikt Meurer authored 
      This is preparatory cleanup work for eventually tracking the functions
(rather than concrete closures) in the CALL_IC, also for builtins like
the default PromiseCapability [[Resolve]] and [[Reject]] functions. It
adds a new FeedbackCell type, which is used by JSFunctions consistently
now to reference the feedback vector (or undefined if not the function
is not compiled yet or is a native/asm.js function).

This also changes the calling convention for FastNewClosure builtin and
the JSCreateClosure operator in TurboFan to carry the FeedbackCell here
instead of the parent FeedbackVector and the slot index. In addition we
eliminate the now unused %InterpreterNewClosure runtime function.

Bug: v8:2206, v8:7253, v8:7310
Change-Id: Ib4ce456e276e0273e57c163dcdd0b33abf863656
Reviewed-on: https://chromium-review.googlesource.com/928403
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51474}
      aff1f378
  9. 12 Feb, 2018 1 commit
    • Ross McIlroy's avatar
      [Ignition] [TurboFan] Generate speculation poison in code generator. · a021b6c4
      Ross McIlroy authored 
      Moves generation of speculation poison to be based on the PC target vs the
actual PC being executed. The speculation poison is generated in the prologue
of the generated code if CompilationInfo::kGenerateSpeculationPoison is set.
The result is stored in a known register, which can then be read using the
SpeculationPoison machine node.

Currently we need to ensure the SpeculationPoison node is scheduled right after
the code prologue so that the poison register doesn't get clobbered. This is
currently not verified, however it's only use is in RawMachineAssembler where
it is manually scheduled early.

The Ignition bytecode handlers are updated to use this speculation poison
rather than one generated by comparing the target bytecode.

BUG=chromium:798964

Change-Id: I2a3d0cfc694e88d7a8fe893282bd5082f693d5e2
Reviewed-on: https://chromium-review.googlesource.com/893160
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51229}
      a021b6c4
  11. 29 Jan, 2018 1 commit
  13. 21 Dec, 2017 1 commit
  15. 14 Dec, 2017 1 commit
  17. 16 Nov, 2017 1 commit
  19. 30 Oct, 2017 1 commit
  21. 25 Oct, 2017 1 commit
  23. 13 Oct, 2017 1 commit
  25. 25 Sep, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Properly optimize literals in inlined functions. · 855b88ae
      Benedikt Meurer authored 
      When inlining based on SharedFunctionInfo rather than based on concrete
JSFunction, we weren't able to properly optimize array, object and
regexp literals inside the inlinee, because we didn't know the concrete
FeedbackVector for the inlinee inside JSCreateLowering. This was because
JSCreateLowering wasn't properly updated after the literals moved to the
FeedbackVector. Now with this CL we also have the VectorSlotPair on the
literal creation operators, just like we do for property accesses and
calls, and are thus able to always access the appropriate FeedbackVector
and optimize the literal creation.

The impact is illustrated by the micro-benchmark on the tracking bug,
which goes from

  createEmptyArrayLiteral: 1846 ms.
  createShallowArrayLiteral: 1868 ms.
  createShallowObjectLiteral: 2246 ms.

to

  createEmptyArrayLiteral: 1175 ms.
  createShallowArrayLiteral: 1187 ms.
  createShallowObjectLiteral: 1195 ms.

with this CL, so up to 2x faster now.

Drive-by-fix: Also remove the unused CreateEmptyObjectLiteral builtin
and cleanup the names of the other builtins to be consistent with the
names of the TurboFan operators and Ignition bytecodes.

Bug: v8:6856
Change-Id: I453828d019b27c9aa1344edac0dd84e91a457097
Reviewed-on: https://chromium-review.googlesource.com/680656
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48140}
      855b88ae
  27. 05 Sep, 2017 1 commit
  29. 01 Sep, 2017 1 commit
  31. 25 Aug, 2017 1 commit
    • Ross McIlroy's avatar
      [Interpreter] Adapt Call bytecode handlers to drop their stack-frame. · 51a15140
      Ross McIlroy authored 
      This change adapts the Call bytecode handlers such that they don't require
a stack frame. It does this by modifying the call bytecode handler to
tail-call the Call or InterpreterPushArgsAndCall builtins. As a result, the
callee function will return to the InterpreterEntryTrampoline when it returns
(since this is the return address on the interpreter frame), which is
adapted to dispatch to the next bytecode handler. The return bytecode
handler is modified to tail-call a new InterpreterExitTramoline instead
of returning to the InterpreterEntryTrampoline.

Overall this significanlty reduces the amount of stack space required for
interpreter frames, increasing the maximum depth of recursive calls from
around 6000 to around 12,500 on x64.

BUG=chromium:753705

Change-Id: I23328e4cef878df3aca4db763b47d72a2cce664c
Reviewed-on: https://chromium-review.googlesource.com/634364
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47617}
      51a15140
  33. 24 Aug, 2017 1 commit
  35. 15 Aug, 2017 1 commit
  37. 07 Aug, 2017 3 commits
    • Benedikt Meurer's avatar
      [ic] Properly integrate the CallIC into Ignition. · ee350c31
      Benedikt Meurer authored 
      Drop the deprecated CallConstructStub and remove the use of CallICStub
from fullcodegen, since that feedback is unused completely every since
Crankshaft got removed, thus we can safely unlink all the CallIC stuff
from fullcodegen nowadays, and completely nuke the CallICStub and the
CallICTrampolineStub now (we can also transitively nuke the unused
CreateAllocationSiteStub and CreateWeakCellStub).

Instead the CallIC logic is integrated into Ignition now, and part of
the bytecode handlers for [[Call]] and [[Construct]]. There's still some
follow-up cleanup with the way the Array constructor feedback is
integrated, but that's way easier now.

Bug: v8:5517, v8:6399, v8:6409, v8:6679
Change-Id: I0a6c6046faceca9b1606577bc9e63d9295e44619
Reviewed-on: https://chromium-review.googlesource.com/603609
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47196}
      ee350c31
    • Michael Achenbach's avatar
      Revert "[ic] Properly integrate the CallIC into Ignition." · 018128a4
      Michael Achenbach authored 
      This reverts commit 6c541561.

Reason for revert:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap/builds/17240

Original change's description:
> [ic] Properly integrate the CallIC into Ignition.
> 
> Drop the deprecated CallConstructStub and remove the use of CallICStub
> from fullcodegen, since that feedback is unused completely every since
> Crankshaft got removed, thus we can safely unlink all the CallIC stuff
> from fullcodegen nowadays, and completely nuke the CallICStub and the
> CallICTrampolineStub now (we can also transitively nuke the unused
> CreateAllocationSiteStub and CreateWeakCellStub).
> 
> Instead the CallIC logic is integrated into Ignition now, and part of
> the bytecode handlers for [[Call]] and [[Construct]]. There's still some
> follow-up cleanup with the way the Array constructor feedback is
> integrated, but that's way easier now.
> 
> Bug: v8:5517, v8:6399, v8:6409, v8:6679
> Change-Id: Ia0efc6145ee64633757a6c3fd1879d4906ea2835
> Reviewed-on: https://chromium-review.googlesource.com/602134
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47192}

TBR=rmcilroy@chromium.org,yangguo@chromium.org,bmeurer@chromium.org

Change-Id: I416ce6646f62ceb4127b3acee43912ee0d701c23
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:5517, v8:6399, v8:6409, v8:6679
Reviewed-on: https://chromium-review.googlesource.com/603647Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47193}
      018128a4
    • Benedikt Meurer's avatar
      [ic] Properly integrate the CallIC into Ignition. · 6c541561
      Benedikt Meurer authored 
      Drop the deprecated CallConstructStub and remove the use of CallICStub
from fullcodegen, since that feedback is unused completely every since
Crankshaft got removed, thus we can safely unlink all the CallIC stuff
from fullcodegen nowadays, and completely nuke the CallICStub and the
CallICTrampolineStub now (we can also transitively nuke the unused
CreateAllocationSiteStub and CreateWeakCellStub).

Instead the CallIC logic is integrated into Ignition now, and part of
the bytecode handlers for [[Call]] and [[Construct]]. There's still some
follow-up cleanup with the way the Array constructor feedback is
integrated, but that's way easier now.

Bug: v8:5517, v8:6399, v8:6409, v8:6679
Change-Id: Ia0efc6145ee64633757a6c3fd1879d4906ea2835
Reviewed-on: https://chromium-review.googlesource.com/602134
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47192}
      6c541561
  39. 19 Jul, 2017 1 commit
  41. 14 Jul, 2017 1 commit
    • Caitlin Potter's avatar
      [generators] remove SuspendFlags enum and related code · 53553f5d
      Caitlin Potter authored 
      SuspendFlags was originally used by the suspend operation to determine
which field to record the bytecode offset of a suspended generator, and
the value the generator was resumed with. For async generators, await
operations would use a separate field, in order to preserve the previous
yield input value. This was important to ensure `function.sent`
continued to function correctly.

As function.sent is being retired, this allows the removal of support
for that. Given that this was the only real need for SuspendFlags in the
first place (with other uses tacked on as a hack), this involves several
other changes as well:

- Modification of MacroAssembler AssertGeneratorObject. No longer
  accepts a SuspendFlags parameter to determine which type of check to
  perform.
- Removal of `flags` operand from SuspendGenerator bytecode, and the
  GeneratorStore js-operator.
- Removal of `flags` parameter from ResumeGeneratorTrampoline builtins.
- Removal of Runtime functions, interpreter intrinsics and
  AccessBuilders associated with the [[await_input_or_debug_pos]] field
  in JSAsyncGeneratorObject, as this field no longer exists.
- Addition of a new `Yield` AST node (subclass of Suspend) in order to
  prevent the need for the other SuspendFlag values.

BUG=v8:5855
TBR=bmeurer@chromium.org

Change-Id: Iff2881e4742497fe5b774915e988c3d9d8fbe487
Reviewed-on: https://chromium-review.googlesource.com/570485
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46683}
      53553f5d
  43. 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
  45. 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
  47. 07 Jun, 2017 1 commit
  49. 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
  51. 21 Apr, 2017 5 commits
  53. 11 Apr, 2017 2 commits
  55. 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
  57. 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
  59. 29 Mar, 2017 1 commit
  61. 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
  63. 14 Feb, 2017 1 commit
  65. 13 Feb, 2017 1 commit