1. 08 Jun, 2017 2 commits
    • bjaideep's avatar
      PPC/s390: Inline Array.prototype.forEach in TurboFan · 0732cbee
      bjaideep authored
      Port 90c3a2d5
      
      Original Commit Message:
      
          This CL contains a few pieces:
      
          - A new mechanism to create "BuiltinContinuation" checkpoints in TurboFan
            graphs, which--when triggered--swizzle the values in the the FrameState to be
            parameters to a typically TF-generated builtin that resumes execution to finish
            the slow-case functionality.
          - Continuation builtins that have special handling in the deoptimizer and their own
            new frame type to ensure that the values they need to begin executing can be stashed
            away and restored immediately before the builtin is called via a trampoline that runs
            when the continuation builtin's frame execution resumes.
          - An implementation of Array.prototype.forEach in TurboFan that can be used to
            inline it. The inlined forEach implementation uses the checkpoints mechanism
            described above to deopt in the middle of the forEach in the cases that optimization
            invariants are violated. There is a slightly different continuation stub for each
            deopt point in the forEach implementation to ensure the correct side-effects, i.e.
            that the deopt of the builtin isn't programmatically observable.
      
      R=danno@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2926043005
      Cr-Commit-Position: refs/heads/master@{#45798}
      0732cbee
    • bjaideep's avatar
      PPC/s390: [debug] Untangle DebugInfo from break point support · 39e42b5e
      bjaideep authored
      Port d3371c23
      
      Original Commit Message:
      
          DebugInfo was very closely tied to break point support:
          * It contained only information relevant to break points.
          * It was created and freed by break point implementation.
          * Existence of a DebugInfo on the shared function info implied existence of
            break points.
      
          This CL is a step towards making DebugInfo usable by other debugging
          functionality such as block coverage by decoupling it from break point support,
          which is now only one kind of information stored on the DebugInfo object.
      
      R=jgruber@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=v8:6000
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2927813004
      Cr-Commit-Position: refs/heads/master@{#45796}
      39e42b5e
  2. 07 Jun, 2017 1 commit
  3. 31 May, 2017 1 commit
    • jgruber's avatar
      [debug] Untangle DebugInfo from break point support · d3371c23
      jgruber authored
      DebugInfo was very closely tied to break point support:
      * It contained only information relevant to break points.
      * It was created and freed by break point implementation.
      * Existence of a DebugInfo on the shared function info implied existence of
        break points.
      
      This CL is a step towards making DebugInfo usable by other debugging
      functionality such as block coverage by decoupling it from break point support,
      which is now only one kind of information stored on the DebugInfo object.
      
      BUG=v8:6000
      
      Review-Url: https://codereview.chromium.org/2909893002
      Cr-Commit-Position: refs/heads/master@{#45640}
      d3371c23
  4. 24 May, 2017 1 commit
  5. 18 May, 2017 2 commits
    • bjaideep's avatar
      PPC/s390: Reland: [Interpreter] Transition JSFunctions to call optimized code when possible. · fc738f1e
      bjaideep authored
      Port 73d21080
      
      Original Commit Message:
      
          Now that the optimized code hangs off the feedback vector, it is possible
          to check whether a function has optimized code available every time it's
          called in the interpreter entry trampoline. If optimized code exists, the
          interpreter entry trampoline 'self-heals' the closure to point to the
          optimized code and links the closure into the optimized code list.
      
      R=rmcilroy@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=v8:6246
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2897483002
      Cr-Commit-Position: refs/heads/master@{#45410}
      fc738f1e
    • 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
  6. 17 May, 2017 2 commits
  7. 09 May, 2017 1 commit
  8. 04 May, 2017 1 commit
    • bjaideep's avatar
      PPC/s390: Reland: [TypeFeedbackVector] Store optimized code in the vector · d5878122
      bjaideep authored
      Port 662aa425
      
      Original Commit Message:
      
          Since the feedback vector is itself a native context structure, why
          not store optimized code for a function in there rather than in
          a map from native context to code? This allows us to get rid of
          the optimized code map in the SharedFunctionInfo, saving a pointer,
          and making lookup of any optimized code quicker.
      
          Original patch by Michael Stanton <mvstanton@chromium.org>
      
      R=rmcilroy@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=v8:6246
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2861863003
      Cr-Commit-Position: refs/heads/master@{#45111}
      d5878122
  9. 27 Apr, 2017 2 commits
  10. 26 Apr, 2017 1 commit
  11. 12 Apr, 2017 2 commits
  12. 11 Apr, 2017 4 commits
  13. 10 Apr, 2017 2 commits
    • bjaideep's avatar
      PPC/s390: [ignition] Add call bytecodes for undefined receiver · 41b22805
      bjaideep authored
      Port 751e8935
      
      Original Commit Message:
      
          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.
      
      R=leszeks@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2809743003
      Cr-Commit-Position: refs/heads/master@{#44539}
      41b22805
    • 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
  14. 31 Mar, 2017 1 commit
  15. 29 Mar, 2017 2 commits
    • bjaideep's avatar
      PPC/s390: [cleanup] combine 3 ResumeGenerator stubs into one · 411efc16
      bjaideep authored
      Port 5615e5b8
      
      Original Commit Message:
      
          This hopefully shrinks binary size a bit, at the cost of (slightly)
          increasing the complexity of the ResumeGenerator stub. Includes ia32,
          x64, mips, mips64, arm and arm64 ports.
      
      R=caitp@igalia.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=v8:5855
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2783043002
      Cr-Commit-Position: refs/heads/master@{#44253}
      411efc16
    • bjaideep's avatar
      PPC/s390: [async-iteration] implement AsyncGenerator · a857e3d0
      bjaideep authored
      Port bf463c4d
      
      Original Commit Message:
      
          - Introduce new struct AsyncGeneratorRequest, which holds
            information pertinent to resuming execution of an
            AsyncGenerator, such as the Promise associated with the async
            generator request. It is intended to be used as a singly
            linked list, and holds a pointer to the next item in te queue.
      
          - Introduce JSAsyncGeneratorObject (subclass of
            JSGeneratorObject), which includes several new internal fields
            (`queue` which contains a singly linked list of
            AsyncGeneratorRequest objects, and `await_input` which
            contains the sent value from an Await expression (This is
            necessary to prevent function.sent (used by yield*) from
            having the sent value observably overwritten during
            execution).
      
          - Modify SuspendGenerator to accept a set of Flags, which
            indicate whether the suspend is for a Yield or Await, and
            whether it takes place on an async generator or ES6
            generator.
      
          - Introduce interpreter intrinsics and TF intrinsic lowering for
            accessing the await input of an async generator
      
          - Modify the JSGeneratorStore operator to understand whether or
            not it's suspending for a normal yield, or an AsyncGenerator
            Await. This ensures appropriate registers are stored.
      
          - Add versions of ResumeGeneratorTrampoline which store the
            input value in a different field depending on wether it's an
            AsyncGenerator Await resume, or an ordinary resume. Also modifies
            whether debug code will assert that the generator object is a
            JSGeneratorObject or a JSAsyncGeneratorObject depending on the
            resume type.
      
      R=caitp@igalia.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=v8:5855
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2780283002
      Cr-Commit-Position: refs/heads/master@{#44247}
      a857e3d0
  16. 27 Mar, 2017 1 commit
  17. 21 Mar, 2017 1 commit
  18. 20 Mar, 2017 1 commit
  19. 14 Mar, 2017 1 commit
  20. 04 Mar, 2017 1 commit
  21. 21 Feb, 2017 1 commit
    • bjaideep's avatar
      PPC/s390: [everywhere] Custom representation for frame type · af76645b
      bjaideep authored
      Port fd596007
      
      Original Commit Message:
      
          Use an opaque format for the frame type marker on the stack, where the
          marker is simply shifted left by 1 instead of being a Smi. This allows
          us to generate simpler code for frame initialisation, as we can push a
          smaller value, decreasing the prologue by 4 bytes and one instruction.
      
      R=leszeks@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2709483007
      Cr-Commit-Position: refs/heads/master@{#43356}
      af76645b
  22. 16 Feb, 2017 1 commit
  23. 15 Feb, 2017 1 commit
  24. 14 Feb, 2017 1 commit
    • vabr's avatar
      Fix TypeError message for Reflect.construct · b478e9c1
      vabr authored
      If the Reflect.construct receives an argument expected to be a constructor,
      and the argument is not a constructor, V8 currently declares that
      Reflect.construct is not a function. It should instead say that the offending
      argument is not a constructor.
      
      This is the case for all ports of builtins
      (Builtins::Generate_ReflectConstruct). All of them make an
      attempt to at least pass the right argument to the TypeError parametrised
      message, calling out the offending Reflect.construct argument. However,
      Runtime::kThrowCalledNonCallable extracts the callsite from those arguments,
      discarding the precise information.
      
      This CL adds Runtime::kNotConstructor, which reports the arguments passed
      to it, and the CL also modifies the ports of builtins to make use of
      Runtime::kNotConstructor
      
      BUG=v8:5671
      
      Review-Url: https://codereview.chromium.org/2688393003
      Cr-Commit-Position: refs/heads/master@{#43182}
      b478e9c1
  25. 13 Feb, 2017 1 commit
    • bjaideep's avatar
      PPC/s390: [turbofan] Correct lazy deopt by {JSCreate} operation. · 2703b06e
      bjaideep authored
      Port 6ee0b6ce
      
      Original Commit Message:
      
          This adds support for deoptimizing into the JSConstructStub after the
          receiver instantiation but before the actual constructor invocation.
          Such a deoptimization point is needed for cases where instantiation
          might be observed (e.g. when new.target is a proxy) and hence might
          trigger a deopt.
      
          We use this new deoptimization point for the "after" frame-state the
          inliner attaches to {JSCreate} nodes being inserted when constructor
          calls are being inlined.
      
      R=mstarzinger@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=v8:5638
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2690213002
      Cr-Commit-Position: refs/heads/master@{#43171}
      2703b06e
  26. 07 Feb, 2017 1 commit
  27. 06 Feb, 2017 1 commit
    • mvstanton's avatar
      [TypeFeedbackVector] Root feedback vectors at function literal site. · aea3ce3d
      mvstanton authored
      TypeFeedbackVectors are strongly rooted by a closure. However, in modern
      JavaScript closures are created and abandoned more freely. An important
      closure may not be present in the root-set at time of garbage collection,
      even though we've cached optimized code and use it regularly. For
      example, consider leaf functions in an event dispatching system. They may
      well be "hot," but tragically non-present when we collect the heap.
      
      Until now, we've relied on a weak root to cache the feedback vector in
      this case. Since there is no way to signal intent or relative importance,
      this weak root is as susceptible to clearing as any other weak root at
      garbage collection time.
      
      Meanwhile, the feedback vector has become more important. All of our
      ICs store their data there. Literal and regex boilerplates are stored there.
      If we lose the vector, then we not only lose optimized code built from
      it, we also lose the very feedback which allowed us to create that optimized
      code. Therefore it's vital to express that dependency through the root
      set.
      
      This CL does this by creating a strong link to a feedback
      vector at the instantiation site of the function closure.
      This instantiation site is in the code and feedback vector
      of the outer closure.
      
      BUG=v8:5456
      
      Review-Url: https://codereview.chromium.org/2674593003
      Cr-Commit-Position: refs/heads/master@{#42953}
      aea3ce3d
  28. 01 Feb, 2017 1 commit
  29. 30 Jan, 2017 2 commits