1. 26 Jan, 2016 3 commits
    • mvstanton's avatar
      Revert of Type Feedback Vector lives in the closure (patchset #12 id:260001 of... · e2e7dc32
      mvstanton authored
      Revert of Type Feedback Vector lives in the closure (patchset #12 id:260001 of https://codereview.chromium.org/1563213002/ )
      
      Reason for revert:
      FAilure on win32 bot, need to investigate webkit failures.
      
      Original issue's description:
      > Type Feedback Vector lives in the closure
      >
      > We get less "pollution" of type feedback if we have one vector per native
      > context, rather than one for the whole system. This CL moves the vector
      > appropriately.
      >
      > We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
      > vector actually lives in the first slot of the literals array (indeed there is
      > great commonality between those arrays, they can be thought of as the same
      > thing). So we make greater effort to ensure there is a valid literals array
      > after compilation.
      >
      > This meant, for performance reasons, that we needed to extend
      > FastNewClosureStub to support creating closures with literals. And ultimately,
      > it drove us to move the optimized code map lookup out of FastNewClosureStub
      > and into the compile lazy builtin.
      >
      > The heap change is trivial so I TBR Hannes for it...
      >
      > TBR=hpayer@chromium.org
      >
      > BUG=
      >
      > Committed: https://crrev.com/a5200f7ed4d11c6b882fa667da7a1864226544b4
      > Cr-Commit-Position: refs/heads/master@{#33518}
      
      TBR=bmeurer@chromium.org,akos.palfi@imgtec.com
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=
      
      Review URL: https://codereview.chromium.org/1632993003
      
      Cr-Commit-Position: refs/heads/master@{#33520}
      e2e7dc32
    • mvstanton's avatar
      Type Feedback Vector lives in the closure · a5200f7e
      mvstanton authored
      We get less "pollution" of type feedback if we have one vector per native
      context, rather than one for the whole system. This CL moves the vector
      appropriately.
      
      We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
      vector actually lives in the first slot of the literals array (indeed there is
      great commonality between those arrays, they can be thought of as the same
      thing). So we make greater effort to ensure there is a valid literals array
      after compilation.
      
      This meant, for performance reasons, that we needed to extend
      FastNewClosureStub to support creating closures with literals. And ultimately,
      it drove us to move the optimized code map lookup out of FastNewClosureStub
      and into the compile lazy builtin.
      
      The heap change is trivial so I TBR Hannes for it...
      
      TBR=hpayer@chromium.org
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1563213002
      
      Cr-Commit-Position: refs/heads/master@{#33518}
      a5200f7e
    • ishell's avatar
      [es6] Tail calls support. · 6131ab1e
      ishell authored
      This CL implements PrepareForTailCall() mentioned in ES6 spec for full codegen, Crankshaft and Turbofan.
      When debugger is active tail calls are disabled.
      
      Tail calling can be enabled by --harmony-tailcalls flag.
      
      BUG=v8:4698
      LOG=Y
      TBR=rossberg@chromium.org
      
      Review URL: https://codereview.chromium.org/1609893003
      
      Cr-Commit-Position: refs/heads/master@{#33509}
      6131ab1e
  2. 25 Jan, 2016 2 commits
    • bmeurer's avatar
      [for-in] Further refactorings and unification around for-in. · 88f9995d
      bmeurer authored
      Cleanup %ForInPrepare runtime entry, and unify common logic with
      %ForInEnumerate (renamed from %GetPropertyNamesFast). Also introduce
      a TupleType to properly type JSForInPrepare and its projections w/o
      special hacks in the Typer. And fix %ForInNext and JSForInNext to be
      consistent with fullcodegen again (after the proxy refactorings last
      quarter).
      
      R=jarin@chromium.org
      BUG=v8:3650
      LOG=n
      
      Review URL: https://codereview.chromium.org/1631583002
      
      Cr-Commit-Position: refs/heads/master@{#33487}
      88f9995d
    • bmeurer's avatar
      [turbofan] Switch JSForInPrepare to %ForInPrepare style. · 825ece48
      bmeurer authored
      Now TurboFan always uses the newly introduced %ForInPrepare, no matter
      whether baseline is the interpreter or fullcodegen. For fullcodegen, we
      introduce a new PrepareId bailout point for this purpose.
      
      Drive-by-fix: Avoid the NoObservableSideEffectsScope in Crankshaft and
      use the PrepareId bailout point instead.
      
      R=jarin@chromium.org
      BUG=v8:3650
      LOG=n
      
      Review URL: https://codereview.chromium.org/1630523002
      
      Cr-Commit-Position: refs/heads/master@{#33480}
      825ece48
  3. 22 Jan, 2016 1 commit
    • bmeurer's avatar
      [stubs] Introduce ToNameStub to implement %_ToName. · a0878333
      bmeurer authored
      We already had hand-written optimized code for %_ToName in fullcodegen,
      but the optimizing compilers always went to the runtime for %_ToName,
      which is pretty bad for many of our builtins. So this CL moves the
      existing native code to a ToNameStub (similar to the existing
      ToStringStub), and uses the ToNameStub consistently in all compilers to
      actually implement %_ToName.
      
      Review URL: https://codereview.chromium.org/1622493002
      
      Cr-Commit-Position: refs/heads/master@{#33460}
      a0878333
  4. 21 Jan, 2016 1 commit
    • bmeurer's avatar
      [for-in] Sanitize for-in optimizations and fix bailout points. · f48bf12f
      bmeurer authored
      The PrepareId bailout location was used incorrectly in Crankshaft and,
      as it turns out, is not required anyway (once you do it right). Also
      there was some premature optimization going on with the CheckEnumCache
      (trying to load null from roots only once), plus we can be smarter about
      the null/undefined check anyway.
      
      The idea behind this changes is to prepare unification of the two
      different ForInPrepare implementations that we now have, with the end
      result being that we only use the new implementation that was recently
      added for the interpreter.
      
      R=jarin@chromium.org
      BUG=v8:3650
      LOG=n
      
      Review URL: https://codereview.chromium.org/1618613002
      
      Cr-Commit-Position: refs/heads/master@{#33426}
      f48bf12f
  5. 19 Jan, 2016 2 commits
  6. 12 Jan, 2016 4 commits
  7. 05 Jan, 2016 1 commit
  8. 04 Jan, 2016 2 commits
  9. 30 Dec, 2015 1 commit
  10. 27 Dec, 2015 2 commits
    • bmeurer's avatar
      [runtime] Introduce dedicated JSBoundFunction to represent bound functions. · 97def807
      bmeurer authored
      According to the ES2015 specification, bound functions are exotic
      objects, and thus don't need to be implemented as JSFunctions. So
      we introduce a new JSBoundFunction type to represent bound functions
      and make them optimizable. This already improves the performance of
      calling or constructing bound functions by 10-100x depending on the
      use case because we avoid the crazy dance between JavaScript and C++
      that was implemented in v8natives.js previously.
      
      There's still room for improvement in the performance of actually
      creating bound functions, which is also relevant in practice, but
      we already have a plan how to accomplish that later.
      
      The mips/mips64 ports were contributed by akos.palfi@imgtec.com.
      
      CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
      BUG=chromium:535408, chromium:571299, v8:4629
      LOG=n
      
      Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2
      Cr-Commit-Position: refs/heads/master@{#33042}
      
      Review URL: https://codereview.chromium.org/1542963002
      
      Cr-Commit-Position: refs/heads/master@{#33044}
      97def807
    • bmeurer's avatar
      Revert of [runtime] Introduce dedicated JSBoundFunction to represent bound... · 1cf8b105
      bmeurer authored
      Revert of [runtime] Introduce dedicated JSBoundFunction to represent bound functions. (patchset #14 id:260001 of https://codereview.chromium.org/1542963002/ )
      
      Reason for revert:
      Breaks arm64 sim nosnap: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20nosnap%20-%20debug/builds/805/steps/Check/logs/function-bind
      
      Original issue's description:
      > [runtime] Introduce dedicated JSBoundFunction to represent bound functions.
      >
      > According to the ES2015 specification, bound functions are exotic
      > objects, and thus don't need to be implemented as JSFunctions. So
      > we introduce a new JSBoundFunction type to represent bound functions
      > and make them optimizable. This already improves the performance of
      > calling or constructing bound functions by 10-100x depending on the
      > use case because we avoid the crazy dance between JavaScript and C++
      > that was implemented in v8natives.js previously.
      >
      > There's still room for improvement in the performance of actually
      > creating bound functions, which is also relevant in practice, but
      > we already have a plan how to accomplish that later.
      >
      > The mips/mips64 ports were contributed by akos.palfi@imgtec.com.
      >
      > CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
      > BUG=chromium:535408, chromium:571299, v8:4629
      > LOG=n
      >
      > Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2
      > Cr-Commit-Position: refs/heads/master@{#33042}
      
      TBR=cbruni@chromium.org,hpayer@chromium.org,yangguo@chromium.org,akos.palfi@imgtec.com
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=chromium:535408, chromium:571299, v8:4629
      
      Review URL: https://codereview.chromium.org/1552473002
      
      Cr-Commit-Position: refs/heads/master@{#33043}
      1cf8b105
  11. 26 Dec, 2015 1 commit
    • bmeurer's avatar
      [runtime] Introduce dedicated JSBoundFunction to represent bound functions. · ca8623ea
      bmeurer authored
      According to the ES2015 specification, bound functions are exotic
      objects, and thus don't need to be implemented as JSFunctions. So
      we introduce a new JSBoundFunction type to represent bound functions
      and make them optimizable. This already improves the performance of
      calling or constructing bound functions by 10-100x depending on the
      use case because we avoid the crazy dance between JavaScript and C++
      that was implemented in v8natives.js previously.
      
      There's still room for improvement in the performance of actually
      creating bound functions, which is also relevant in practice, but
      we already have a plan how to accomplish that later.
      
      The mips/mips64 ports were contributed by akos.palfi@imgtec.com.
      
      CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
      BUG=chromium:535408, chromium:571299, v8:4629
      LOG=n
      
      Review URL: https://codereview.chromium.org/1542963002
      
      Cr-Commit-Position: refs/heads/master@{#33042}
      ca8623ea
  12. 23 Dec, 2015 1 commit
    • mvstanton's avatar
      Partial revert of rest parameter desugaring. · d3f074b2
      mvstanton authored
      We'll be able to optimize rest parameters in TurboFan similarly to the arguments array. This CL restores the previous behavior, and a follow-on will enable TurboFan optimization.
      
      (TBR for rossberg since we discussed the revert beforehand. The only changes are a few lines related to tests and rebasing.)
      
      TBR=rossberg@chromium.org
      BUG=
      
      Review URL: https://codereview.chromium.org/1537683002
      
      Cr-Commit-Position: refs/heads/master@{#33024}
      d3f074b2
  13. 17 Dec, 2015 1 commit
    • Benedikt Meurer's avatar
      [runtime] Drop FIRST/LAST_NONCALLABLE_SPEC_OBJECT instance type range. · aafc3e54
      Benedikt Meurer authored
      The FIRST-LAST_NONCALLABLE_SPEC_OBJECT_TYPE range was accidentially used
      in field type tracking, where we should check for JSReceiver instead
      (there's no need to exclude JSProxy or JSFunction from tracking).
      
      And the use in %_ClassOf was actually wrong and didn't match the C++
      implementation in JSReceiver::class_name() anymore. Now it's consistent
      again.
      
      R=yangguo@chromium.org
      BUG=chromium:535408
      LOG=n
      
      Review URL: https://codereview.chromium.org/1535523003 .
      
      Cr-Commit-Position: refs/heads/master@{#32926}
      aafc3e54
  14. 16 Dec, 2015 1 commit
  15. 14 Dec, 2015 1 commit
  16. 11 Dec, 2015 3 commits
  17. 05 Dec, 2015 1 commit
  18. 04 Dec, 2015 2 commits
  19. 03 Dec, 2015 1 commit
    • mstarzinger's avatar
      [fullcode] Switch passing of new.target to register. · 440a42b7
      mstarzinger authored
      This passes the new.target value in a register instead of through a
      side-channel via the construct stub. Note that this marks the last
      consumer of said side-channel and the special slot in the construct
      stub frame can be removed as a follow-up.
      
      R=bmeurer@chromium.org,yangguo@chromium.org
      TEST=mjsunit/es6/regress/regress-new-target-context
      
      Review URL: https://codereview.chromium.org/1492793002
      
      Cr-Commit-Position: refs/heads/master@{#32548}
      440a42b7
  20. 02 Dec, 2015 2 commits
  21. 01 Dec, 2015 2 commits
  22. 30 Nov, 2015 4 commits
  23. 27 Nov, 2015 1 commit