1. 04 Mar, 2017 1 commit
  2. 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
  3. 16 Feb, 2017 1 commit
  4. 15 Feb, 2017 1 commit
  5. 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
  6. 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
  7. 07 Feb, 2017 1 commit
  8. 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
  9. 01 Feb, 2017 1 commit
  10. 30 Jan, 2017 2 commits
  11. 27 Jan, 2017 1 commit
    • bjaideep's avatar
      PPC/s390: [turbofan] Introduce JSCallForwardVarargs operator. · e6688728
      bjaideep authored
      Port 69747e26
      
      Original Commit Message:
      
          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=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=v8:5267,v8:5726
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2656363002
      Cr-Commit-Position: refs/heads/master@{#42745}
      e6688728
  12. 26 Jan, 2017 1 commit
    • bjaideep's avatar
      PPC/s390: [Turbofan] Implement call with spread bytecode in assembly code. · cc075f0e
      bjaideep authored
      Port f9367847
      Port bf782ec5
      
      Original Commit Message:
      
          We can share almost all of the architecture-specific builtin code with super-call-with-spread.
      
          Info to port-writers: The code in CheckSpreadAndPushToStack has changed slightly
          from what was in Generate_ConstructWithSpread, in that we take the length of the
          spreaded parameters from the JSArray rather than the FixedArray backing store.
      
      R=petermarshall@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=v8:5511
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2655043004
      Cr-Commit-Position: refs/heads/master@{#42708}
      cc075f0e
  13. 24 Jan, 2017 1 commit
  14. 23 Jan, 2017 1 commit
  15. 20 Jan, 2017 1 commit
  16. 19 Jan, 2017 3 commits
  17. 18 Jan, 2017 3 commits
  18. 17 Jan, 2017 2 commits
    • bjaideep's avatar
      PPC/s390: [builtins] CompileLazy bailed out to the runtime entirely too often. · bb89869a
      bjaideep authored
      Port 743fdb25
      
      Original Commit Message:
      
          This is just a bug. CompileLazy knows how to look in the
          SharedFunctionInfo for code (or bytecode, essentially) if it
          finds nothing in the OptimizedCodeMap. Ensure that behavior.
      
      R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=681543
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2641473002
      Cr-Commit-Position: refs/heads/master@{#42422}
      bb89869a
    • neis's avatar
      [generators] Always call function with closure context when resuming. · c5948b98
      neis authored
      The resume trampolin used to call the generator function with the context of the
      last suspension rather than the closure's context.  While that was fine for
      Ignition, Turbofan got utterly confused.  With this CL, the resume trampolin
      always passes in the closure's context (like in the very first call of the
      generator function).  The generator function itself then restores its previously
      current context by reading it from the generator object and doing a
      PushContext.
      
      BUG=chromium:681171
      
      Review-Url: https://codereview.chromium.org/2639533002
      Cr-Commit-Position: refs/heads/master@{#42407}
      c5948b98
  19. 12 Jan, 2017 2 commits
  20. 03 Jan, 2017 1 commit
    • bjaideep's avatar
      PPC/s390: [Ignition] Teach CompileLazy about interpreted functions. · 7d52258b
      bjaideep authored
      Port 72c37076
      
      Original Commit Message:
      
          Currently the CompileLazy builtin checks the SFI expliciltly for FCG code. This means
          if the SFI has bytecode we have to go through to the runtime to install the
          interpreter entry trampoline into the JSFunction object.
      
          Modify the builtin to always put the SFI code object into the JSFunction unless it's
          the lazy compile stub on the SFI as well.
      
      R=rmcilroy@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=v8:4380
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2602383003
      Cr-Commit-Position: refs/heads/master@{#42046}
      7d52258b
  21. 29 Dec, 2016 1 commit
  22. 27 Dec, 2016 1 commit
  23. 21 Dec, 2016 1 commit
    • bjaideep's avatar
      PPC/s390: [TypeFeedbackVector] Root literal arrays in function literals slots · 19aa7a20
      bjaideep authored
      Port 93df0940
      
      Original Commit Message:
      
          Literal arrays and feedback vectors for a function can be garbage
          collected if we don't have a rooted closure for the function, which
          happens often. It's expensive to come back from this (recreating
          boilerplates and gathering feedback again), and the cost is
          disproportionate if the function was inlined into optimized code.
      
          To guard against losing these arrays when we need them, we'll now
          create literal arrays when creating the feedback vector for the outer
          closure, and root them strongly in that vector.
      
      R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=v8:5456
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2592043003
      Cr-Commit-Position: refs/heads/master@{#41898}
      19aa7a20
  24. 10 Dec, 2016 1 commit
  25. 07 Dec, 2016 1 commit
    • bjaideep's avatar
      PPC/s390: Store OSR'd optimized code on the native context. · 3bc53ad7
      bjaideep authored
      Port 378b6b22
      
      Original Commit Message:
      
          Since we OSR code rarely, it makes sense to store it and look for
          it on the native context rather than the SharedFunctionInfo.
          This makes the OptimizedCodeMap data structure more space efficient,
          as it doesn't have to store an ast ID for the OSR entry point.
      
      R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2557113002
      Cr-Commit-Position: refs/heads/master@{#41562}
      3bc53ad7
  26. 29 Nov, 2016 2 commits
  27. 21 Nov, 2016 1 commit
    • mstarzinger's avatar
      [fullcodegen] Remove deprecated generator implementation. · 09255541
      mstarzinger authored
      This removes the deprecated generator support for resumable functions
      from {FullCodeGenerator}. The existing {AstNumbering} heuristic already
      triggers Ignition for most resumable functions, with this change we make
      said heuristic a hard choice and remove the deprecated code. This also
      has the advantage that any suspended {JSGeneratorObject} instance on the
      heap is guaranteed to have code based on a bytecode array.
      
      R=bmeurer@chromium.org
      
      Review-Url: https://codereview.chromium.org/2504223002
      Cr-Commit-Position: refs/heads/master@{#41135}
      09255541
  28. 10 Nov, 2016 1 commit
    • bjaideep's avatar
      PPC/s390: [turbofan] Advance bytecode offset after lazy deopt. · a5467aae
      bjaideep authored
      Port 93c65952
      
      Original commit message:
      
          This changes {FrameState} nodes modeling "after" states to use bytecode
          offsets pointing to the deoptimizing bytecode. This is in sync with the
          normal execution, as the bytecode offset is advanced after operations
          complete in regular bytecode handlers.
      
          The change is necessary to ensure lazy deoptimized frames contain an
          accurate bytecode offset while they are on the stack. Such frames can be
          inspected by various stack walks. The continuation builtin will advance
          the bytecode offset upon return.
      
      R=mstarzinger@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2486393005
      Cr-Commit-Position: refs/heads/master@{#40898}
      a5467aae
  29. 04 Nov, 2016 1 commit
    • mstarzinger's avatar
      [compiler] Remove --ignition-preserve-bytecode flag. · 01219881
      mstarzinger authored
      This removes the deprecated flag in question which has been enabled by
      default a while ago. All components can by now deal with activations of
      a single function being mixed between Ignition and other compilers. The
      maintenance overhead to support a mode that clears bytecode is no longer
      warranted.
      
      R=rmcilroy@chromium.org
      BUG=v8:4280
      
      Review-Url: https://codereview.chromium.org/2475203003
      Cr-Commit-Position: refs/heads/master@{#40776}
      01219881
  30. 27 Oct, 2016 1 commit
  31. 21 Oct, 2016 1 commit
    • leszeks's avatar
      [compiler] Mark shared functions for optimization · 4a31323e
      leszeks authored
      The current method of marking functions for optimization, which replaces
      the JSFunction's code object with one that triggers optimization, would
      never allow unnamed functions to be optimized. This is an issue for a
      style of programming which heavily relies on passing around closures.
      
      This patch sets a bit on the SharedFunctionInfo when a JSFunction is
      marked. When another JSFunction referring to the same SharedFunctionInfo
      is lazily compiled, it immediately triggers a non-concurrent optimize.
      
      BUG=v8:5512
      
      Review-Url: https://chromiumcodereview.appspot.com/2437043002
      Cr-Commit-Position: refs/heads/master@{#40506}
      4a31323e
  32. 19 Oct, 2016 1 commit