1. 22 Jun, 2018 1 commit
  2. 21 Jun, 2018 2 commits
  3. 18 Jun, 2018 1 commit
  4. 12 Jun, 2018 1 commit
  5. 07 Jun, 2018 1 commit
  6. 30 May, 2018 1 commit
  7. 28 May, 2018 1 commit
  8. 08 May, 2018 1 commit
    • Junliang Yan's avatar
      PPC/s390: [builtins] Convert CEntry/GetProperty/StringAdd stubs to builtins · 7ff35bd5
      Junliang Yan authored
      Port d8131cd6
      
      Original Commit Message:
      
          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.
      
      R=jgruber@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: I193e4275470d492912a7d0f8523c3b8c29f1b146
      Reviewed-on: https://chromium-review.googlesource.com/1050732
      Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
      Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#53081}
      7ff35bd5
  9. 03 May, 2018 1 commit
  10. 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
  11. 13 Feb, 2018 1 commit
    • Junliang Yan's avatar
      PPC/s390: [Ignition] [TurboFan] Generate speculation poison in code generator. · abac06aa
      Junliang Yan authored
      Port a021b6c4
      
      Original Commit Message:
      
          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.
      
      R=rmcilroy@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=chromium:798964
      LOG=N
      
      Change-Id: I4b9a1b0865b6164171cf83f0e45c36c69ac08a18
      Reviewed-on: https://chromium-review.googlesource.com/914848Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
      Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#51273}
      abac06aa
  12. 31 Jan, 2018 1 commit
  13. 21 Dec, 2017 1 commit
  14. 14 Dec, 2017 1 commit
  15. 22 Nov, 2017 1 commit
  16. 30 Oct, 2017 1 commit
  17. 25 Oct, 2017 1 commit
  18. 13 Oct, 2017 1 commit
  19. 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
  20. 06 Sep, 2017 1 commit
    • Anisha Rohra's avatar
      s390/PPC: Remove InterpreterExitTrampoline. · 40c98daa
      Anisha Rohra authored
      Port 30f08f39
      
        Always return to the InterpreterEntryTrampoline rather than calling the
        InterpreterExitTrampoline from the Return bytecode handler. This fixes a
        regression which occured if we upset the call/return stack by skipping the
        return to the InterpreterEntryTrampoline from the return bytecode handler.
      
      R=bjaideep@ca.ibm.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: Id2bae444e72cd7ddfb74f4861fc2c4f7b5e9bda5
      Reviewed-on: https://chromium-review.googlesource.com/653618Reviewed-by: 's avatarJaideep Bajwa <bjaideep@ca.ibm.com>
      Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#47858}
      40c98daa
  21. 01 Sep, 2017 1 commit
  22. 29 Aug, 2017 1 commit
    • Jaideep Bajwa's avatar
      PPC/s390: [Interpreter] Adapt Call bytecode handlers to drop their stack-frame. · e5b93bd5
      Jaideep Bajwa authored
      Port 51a15140
      
      Original Commit Message:
      
          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.
      
      R=rmcilroy@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=chromium:753705
      LOG=N
      
      Change-Id: Ieac490d82098c13741080061eda762d54baf8c04
      Reviewed-on: https://chromium-review.googlesource.com/639315Reviewed-by: 's avatarJunliang Yan <jyan@ca.ibm.com>
      Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#47694}
      e5b93bd5
  23. 24 Aug, 2017 1 commit
  24. 15 Aug, 2017 1 commit
  25. 08 Aug, 2017 1 commit
  26. 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
  27. 26 Jul, 2017 1 commit
  28. 19 Jul, 2017 1 commit
  29. 23 Jun, 2017 1 commit
    • Jaideep Bajwa's avatar
      PPC/s390: [runtime] Port SpreadCall code to CSA. · 789f9592
      Jaideep Bajwa authored
      Port a971a64d
      
      Original Commit Message:
      
          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.
      
      R=petermarshall@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: Idad830c9aace4151db866c9f863158cd7525e881
      Reviewed-on: https://chromium-review.googlesource.com/546575Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
      Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#46187}
      789f9592
  30. 09 Jun, 2017 1 commit
    • bjaideep's avatar
      PPC/s390: [builtins] Start refactoring the Apply builtin. · 9385fd40
      bjaideep authored
      Port af76779a
      
      Original Commit Message:
      
          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=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=v8:4587,v8:5269
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2932833002
      Cr-Commit-Position: refs/heads/master@{#45826}
      9385fd40
  31. 07 Jun, 2017 1 commit
  32. 18 May, 2017 1 commit
    • bjaideep's avatar
      PPC/s390: [turbofan] Avoid allocating rest parameters for spread calls. · f4da4361
      bjaideep authored
      Port bfa319e5
      
      Original Commit Message:
      
          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.
      
      R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=v8:6407,v8:6278,v8:6344
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2887153004
      Cr-Commit-Position: refs/heads/master@{#45402}
      f4da4361
  33. 21 Apr, 2017 5 commits