1. 08 May, 2017 1 commit
  2. 26 Apr, 2017 1 commit
  3. 04 Apr, 2017 2 commits
  4. 29 Mar, 2017 1 commit
    • Caitlin Potter's avatar
      [async-iteration] implement AsyncGenerator · bf463c4d
      Caitlin Potter authored
      - 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.
      
      BUG=v8:5855
      R=bmeurer@chromium.org, rmcilroy@chromium.org, jgruber@chromium.org,
      littledan@chromium.org, neis@chromium.org
      TBR=marja@chromium.org
      
      Change-Id: I9d58df1d344465fc937fe7eed322424204497187
      Reviewed-on: https://chromium-review.googlesource.com/446961
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44240}
      bf463c4d
  5. 12 Feb, 2017 2 commits
  6. 09 Feb, 2017 1 commit
  7. 20 Jan, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Properly implement %_ClassOf intrinsic. · 3e407093
      bmeurer authored
      The %_ClassOf intrinsic roughly corresponds to the deprecated ES5
      [[Class]] internal property, and should not be used anymore ideally.
      However since we still have quite a couple of uses of this intrinsic
      in the self hosted JavaScript builtins, we would tank some builtins
      like Map, Set, WeakMap, WeakSet, etc. quite significantly unless we
      also support this intrinsic until the builtins are all migrated to
      C++/CSA builtins.
      
      R=yangguo@chromium.org
      BUG=v8:5267
      
      Review-Url: https://codereview.chromium.org/2647833004
      Cr-Commit-Position: refs/heads/master@{#42530}
      3e407093
  8. 19 Jan, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Recognize a couple of collection.js intrinsics. · d389e49b
      bmeurer authored
      Right now running the Map and Set builtins with I+TF would tank
      seriously because these builtins are still built on top of a
      couple of classic intrinsics that TurboFan doesn't understand.
      Middle-term the idea is to replace the Map and Set builtins with
      a CodeStubAssembler based solution, but for that might not be
      ready in time, so adding support for a couple of the critical
      intrinsics to mitigate the tankage a bit, namely
      
       - %_JSCollectionGetTable,
       - %_TheHole, and
       - %_StringGetRawHashField.
      
      Together these double the score on most of the existing performance
      tests for collections.
      
      R=yangguo@chromium.org
      BUG=v8:5267
      
      Review-Url: https://codereview.chromium.org/2647733002
      Cr-Commit-Position: refs/heads/master@{#42521}
      d389e49b
  9. 17 Jan, 2017 1 commit
    • 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
  10. 22 Dec, 2016 1 commit
  11. 04 Dec, 2016 1 commit
  12. 25 Oct, 2016 1 commit
    • jgruber's avatar
      [regexp] Remove unused code · 77ddcfb3
      jgruber authored
      This CL removes code that is now unused since the port of regexp.js has been
      completed. Removed functions / classes are:
      
      * regexp.js (GetSubstitution moved to string.js)
      * RegExpConstructResult stub
      * RegExpFlags intrinsic
      * RegExpSource intrinsic
      * RegExpInitializeAndCompile runtime function
      
      BUG=v8:5339
      
      Review-Url: https://codereview.chromium.org/2448463002
      Cr-Commit-Position: refs/heads/master@{#40547}
      77ddcfb3
  13. 17 Oct, 2016 1 commit
  14. 25 Jul, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Avoid introducing machine operators during typed lowering. · 5bed1516
      bmeurer authored
      Introducing machine operators early causes trouble for the typing,
      truncation analysis and representation selection, so we should rather
      stick to simplified operators instead. Now there's only the for-in case
      left, which is not clear how we can handle this in a better way.
      
      Drive-by-fix: Also don't introduce Int32Constant and Word32Shl in
      JSTypedLowering, but use NumberConstant and proper NumberShiftLeft
      operators instead.
      
      R=jarin@chromium.org
      BUG=chromium:630951
      
      Review-Url: https://codereview.chromium.org/2182453002
      Cr-Commit-Position: refs/heads/master@{#38008}
      5bed1516
  15. 12 Jul, 2016 1 commit
  16. 05 Jul, 2016 3 commits
  17. 29 Jun, 2016 1 commit
  18. 21 Jun, 2016 1 commit
    • neis's avatar
      [generators] Implement %GeneratorGetSourcePosition. · 7c57ffc1
      neis authored
      This runtime function now also works for Ignition generators. It returns the
      source position of the yield at which a suspended generator got suspended.  This
      works by storing the current bytecode offset at suspension and using an existing
      mechanism to map it back to a source position.
      
      TBR=littledan@chromium.org
      BUG=
      
      Review-Url: https://codereview.chromium.org/2079613003
      Cr-Commit-Position: refs/heads/master@{#37140}
      7c57ffc1
  19. 20 Jun, 2016 1 commit
    • bmeurer's avatar
      [builtins] Introduce proper Float64Tan operator. · c87168bc
      bmeurer authored
      Import base::ieee754::tan() from fdlibm and introduce Float64Tan TurboFan
      operator based on that, similar to what we do for Float64Cos and Float64Sin.
      Rewrite Math.tan() as TurboFan builtin and use those operators to also
      inline Math.tan() into optimized TurboFan functions.
      
      Drive-by-fix: Kill the %_ConstructDouble intrinsics, and provide only
      the %ConstructDouble runtime entry for writing tests.
      
      BUG=v8:5086,v8:5126
      R=yangguo@chromium.org
      
      Review-Url: https://codereview.chromium.org/2083453002
      Cr-Commit-Position: refs/heads/master@{#37087}
      c87168bc
  20. 23 May, 2016 1 commit
  21. 20 May, 2016 1 commit
  22. 17 May, 2016 1 commit
    • bmeurer's avatar
      [es6] Reintroduce the instanceof operator in the backends. · 551e0aa1
      bmeurer authored
      This adds back the instanceof operator support in the backends and
      introduces a @@hasInstance protector cell on the isolate that guards the
      fast path for the InstanceOfStub. This way we recover the ~10%
      regression on Octane EarleyBoyer in Crankshaft and greatly improve
      TurboFan and Ignition performance of instanceof.
      
      R=ishell@chromium.org
      TBR=hpayer@chromium.org,rossberg@chromium.org
      BUG=chromium:597249, v8:4447
      LOG=n
      
      Review-Url: https://codereview.chromium.org/1980483003
      Cr-Commit-Position: refs/heads/master@{#36275}
      551e0aa1
  23. 11 Apr, 2016 1 commit
  24. 01 Apr, 2016 3 commits
  25. 28 Mar, 2016 1 commit
    • bmeurer's avatar
      [builtins] Provide Math.floor as TurboFan builtin. · 36ead519
      bmeurer authored
      This way we avoid the second deoptimization for the Math.floor and
      Math.ceil builtins when -0 is involved. We still deoptimize the inlined
      Crankshaft version in various cases, that's a separate issue.
      
      The algorithm used for implement CodeStubAssembler::Float64Floor is
      vaguely based on the fast math version used in the libm of various BSDs,
      but had to be reengineered to match the EcmaScript specification.
      
      R=epertoso@chromium.org
      BUG=v8:2890, v8:4059
      LOG=n
      
      Review URL: https://codereview.chromium.org/1828253002
      
      Cr-Commit-Position: refs/heads/master@{#35083}
      36ead519
  26. 22 Mar, 2016 2 commits
  27. 17 Mar, 2016 1 commit
  28. 26 Feb, 2016 1 commit
    • bmeurer's avatar
      [runtime] Remove obsolete %Apply and %TailCall runtime entries. · 7f11fba7
      bmeurer authored
      The %TailCall runtime entry and the %_TailCall intrinsic is not used,
      and will never be used (because %TailCall doesn't actually do a tail
      call). We will soon have proper ES6 tail calls, which are correct and
      properly tested.
      
      The %Apply runtime entry is basically a super-slow, less correct version
      of Reflect.apply, so we can as well just use Reflect.apply, which is
      exposed to builtins via %reflect_apply.
      
      R=ishell@chromium.org
      
      Review URL: https://codereview.chromium.org/1739233002
      
      Cr-Commit-Position: refs/heads/master@{#34317}
      7f11fba7
  29. 16 Feb, 2016 1 commit
  30. 09 Feb, 2016 1 commit
    • bmeurer's avatar
      [intrinsics] Kill the %_IsMinusZero intrinsic. · 00f7d1f5
      bmeurer authored
      By now only the default %TypedArray%.prototype.sort compare function
      and the JS implementation of SameValueZero were still using the odd
      %_IsMinusZero intrinsic, whose semantics both included a number check
      (actually HeapNumber test) plus testing if the heap number stores the
      special -0 value. In both cases we already know that we deal with
      number so we can reduce it to a simple number test for -0, which can
      be expressed via dividing 1 by that value and checking the sign of
      the result. In case of the compare function, we can be even smarter
      and work with the reciprocal values in case x and y are equal to 0
      (although long term we should probably rewrite the fast case for
      the typed array sorting function in C++ anyway, which will be way,
      way faster than our handwritten callback-style, type-feedback
      polluted JS implementation).
      
      R=yangguo@chromium.org
      
      Review URL: https://codereview.chromium.org/1680783002
      
      Cr-Commit-Position: refs/heads/master@{#33833}
      00f7d1f5
  31. 02 Feb, 2016 1 commit
  32. 12 Jan, 2016 2 commits