1. 13 Jul, 2017 1 commit
  2. 05 Jul, 2017 1 commit
  3. 22 Jun, 2017 1 commit
  4. 20 Jun, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Introduce new JSCallWithArrayLike operator. · 767ce788
      bmeurer authored
      Add a new JSCallWithArrayLike operator that is backed by the
      CallWithArrayLike builtin, and use that operator for both
      Function.prototype.apply and Reflect.apply inlining. Also unify
      the handling of JSCallWithArrayLike and JSCallWithSpread in
      the JSCallReducer to reduce the copy&paste overhead.
      
      Drive-by-fix: Add a lot of test coverage for Reflect.apply and
      Function.prototype.apply in optimized code, especially for some
      corner cases, which was missing so far.
      
      BUG=v8:4587,v8:5269
      R=petermarshall@chromium.org
      
      Review-Url: https://codereview.chromium.org/2950773002
      Cr-Commit-Position: refs/heads/master@{#46041}
      767ce788
  5. 19 Jun, 2017 1 commit
  6. 12 Jun, 2017 1 commit
  7. 08 Jun, 2017 1 commit
    • bmeurer's avatar
      [builtins] Start refactoring the Apply builtin. · af76779a
      bmeurer authored
      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=petermarshall@chromium.org
      BUG=v8:4587,v8:5269
      
      Review-Url: https://codereview.chromium.org/2930623002
      Cr-Commit-Position: refs/heads/master@{#45794}
      af76779a
  8. 31 May, 2017 1 commit
  9. 18 May, 2017 2 commits
  10. 17 May, 2017 1 commit
  11. 05 May, 2017 1 commit
  12. 29 Apr, 2017 5 commits
  13. 21 Apr, 2017 5 commits
  14. 11 Apr, 2017 2 commits
  15. 10 Apr, 2017 1 commit
    • 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
  16. 29 Mar, 2017 2 commits
    • Caitlin Potter's avatar
      [cleanup] combine 3 ResumeGenerator stubs into one · 5615e5b8
      Caitlin Potter authored
      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.
      
      BUG=v8:5855
      R=rmcilroy@chromium.org, paul.lind@imgtec.com, bmeurer@chromium.org, neis@chromium.org
      
      Change-Id: I848ce08afd828091a11e03c89d5be065ff557ef3
      Reviewed-on: https://chromium-review.googlesource.com/461303
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44244}
      5615e5b8
    • 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
  17. 24 Mar, 2017 3 commits
  18. 21 Mar, 2017 3 commits
  19. 16 Mar, 2017 2 commits
    • danno's avatar
      [builtins] Separate Array.prototype.* CSA builtins into two parts · 7de21c4d
      danno authored
      Previous to this CL, CSA-optimized Array builtins--like forEach, some, and
      every--were written in a single, monolithic block of CSA code.
      
      This CL teases the code for each of these builtins apart into two chunks, a main
      body with optimizations for fast cases, and a "continuation" builtin that
      performs a spec-compliant, but slower version of the main loop of the
      builtin. The general idea is that when the "fast" main body builtin encounters
      an unexpected condition that invalidates assumptions allowing fast-case code, it
      tail calls to the slow, correct version of the loop that finishes the builtin
      execution.
      
      This separation currently doens't really provide any specific advantage over the
      combined version. However, it paves the way to TF-optimized inlined Array
      builtins. Inlined Array builtins may trigger deopts during the execution of the
      builtin's loop, and those deopt must continue execution from the point at which
      they failed. With some massaging of the deoptimizer, it will be possible to make
      those deopt points create an extra frame on the top of the stack which resumes
      execution in the slow-loop builtin created in this CL.
      
      BUG=v8:1956
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2753793002
      Cr-Commit-Position: refs/heads/master@{#43867}
      7de21c4d
    • jgruber's avatar
      [csa] Add CSA::CallBuiltin and Builtins::CallableFor · a4c73fa7
      jgruber authored
      This is another step towards making calls to builtins more convenient.
      
      Builtins::CallableFor is an automatically generated Callable accessor for TFS
      builtins (whereas previously we had to manually add an accessor to
      code-factory.{h,cc}).
      
      CSA::CallBuiltin is a convenience wrapper around CallStub for TFS builtins.
      
      We can begin removing accessors for TFS builtins from CodeFactory in an
      upcoming commit.
      
      BUG=v8:5737
      
      Review-Url: https://codereview.chromium.org/2752213002
      Cr-Commit-Position: refs/heads/master@{#43865}
      a4c73fa7
  20. 14 Mar, 2017 1 commit
  21. 07 Mar, 2017 2 commits
    • jgruber's avatar
      [ic] Inline LoadIC into LdaNamedProperty bytecode handler · 0bfabaf1
      jgruber authored
      This inlines common LoadIC cases into the LdaNamedProperty bytecode
      handler. Smi handlers resulting in constant/field loads for
      monomorphic ICs omit frame construction. The same counts for the
      polymorphic case as long as the target handler is in the first two
      vector slots.
      
      Other cases (megamorphic, uninitialized) call the new
      LoadIC_Noninlined stub.
      
      Local benchmarks show up to 6% improvement on Sunspider with --future.
      
      BUG=v8:5917
      
      Review-Url: https://codereview.chromium.org/2733563002
      Cr-Commit-Position: refs/heads/master@{#43630}
      0bfabaf1
    • Michael Starzinger's avatar
      Remove dead handling of Token::NE from all backends. · aa894aff
      Michael Starzinger authored
      The parser already changes all negative equality comparison operations
      to their positive pendants in {ParserBase::ParseBinaryExpression}. No
      other source of the Token::NE exists in the system. We can remove all
      handling from the compiler and interpreter backends.
      
      R=bmeurer@chromium.org
      
      Change-Id: I58722c08dd8e498f20c65886fce86b8172737b10
      Reviewed-on: https://chromium-review.googlesource.com/449716Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#43627}
      aa894aff
  22. 03 Mar, 2017 1 commit
  23. 28 Feb, 2017 1 commit
    • tebbi's avatar
      [turbofan] escape analysis supports arguments object and rest elements · 7467f16d
      tebbi authored
      The new NewUnmappedArgumentsElements node now takes two inputs:
      - the frame holding the arguments (current frame or arguments adaptor frame)
      - the length of the suffix of passed arguments to be copied into the backing store
      
      These inputs are computed with two new node types:
      ArgumentsFrame()
      ArgumentsLength[formal_parameter_count,is_rest_length](Node* arguments_frame)
      The node type NewRestParameterElements can now be expressed with NewUnmappedArgumentsElements and an appropriate length and is thus not needed anymore.
      
      In escape analysis, we lower loads from the length field of NewUnmappedArgumentsElements with its length input and if we find out that no write access to the arguments elements exists, we replace element loads with direct stack access and replace the NewUnmappedArgumentsElements node with a node of the new node type ArgumentsElementsState. This corresponds to an ObjectState node and gets translated into a deoptimizer instruction to allocate the backing store. Together with the already existing deoptimizer support for the actual arguments object/rest parameters, this allows to remove all allocations for arguments objects/rest parameters in this case.
      In the deoptimizer, we read the actual parameters from the stack while transforming the static deopt info into TranslatedValue objects.
      
      If escape analysis cannot remove the backing store allocation, NewUnmappedArgumentsElements gets lo
      
      BUG=v8:5726
      
      Review-Url: https://codereview.chromium.org/2692753004
      Cr-Commit-Position: refs/heads/master@{#43475}
      7467f16d