1. 19 Jul, 2017 1 commit
  2. 14 Jul, 2017 1 commit
    • Caitlin Potter's avatar
      [generators] remove SuspendFlags enum and related code · 53553f5d
      Caitlin Potter authored
      SuspendFlags was originally used by the suspend operation to determine
      which field to record the bytecode offset of a suspended generator, and
      the value the generator was resumed with. For async generators, await
      operations would use a separate field, in order to preserve the previous
      yield input value. This was important to ensure `function.sent`
      continued to function correctly.
      
      As function.sent is being retired, this allows the removal of support
      for that. Given that this was the only real need for SuspendFlags in the
      first place (with other uses tacked on as a hack), this involves several
      other changes as well:
      
      - Modification of MacroAssembler AssertGeneratorObject. No longer
        accepts a SuspendFlags parameter to determine which type of check to
        perform.
      - Removal of `flags` operand from SuspendGenerator bytecode, and the
        GeneratorStore js-operator.
      - Removal of `flags` parameter from ResumeGeneratorTrampoline builtins.
      - Removal of Runtime functions, interpreter intrinsics and
        AccessBuilders associated with the [[await_input_or_debug_pos]] field
        in JSAsyncGeneratorObject, as this field no longer exists.
      - Addition of a new `Yield` AST node (subclass of Suspend) in order to
        prevent the need for the other SuspendFlag values.
      
      BUG=v8:5855
      TBR=bmeurer@chromium.org
      
      Change-Id: Iff2881e4742497fe5b774915e988c3d9d8fbe487
      Reviewed-on: https://chromium-review.googlesource.com/570485
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46683}
      53553f5d
  3. 13 Jul, 2017 1 commit
  4. 12 Jul, 2017 1 commit
  5. 29 Jun, 2017 1 commit
  6. 21 Jun, 2017 1 commit
  7. 19 Jun, 2017 1 commit
  8. 13 Jun, 2017 1 commit
    • bmeurer's avatar
      [builtins] Properly optimize Object.prototype.isPrototypeOf. · b11c557d
      bmeurer authored
      Port the baseline implementation of Object.prototype.isPrototypeOf to
      the CodeStubAssembler, sharing the existing prototype chain lookup logic
      with the instanceof / OrdinaryHasInstance implementation. Based on that,
      do the same in TurboFan, introducing a new JSHasInPrototypeChain
      operator, which encapsulates the central prototype chain walk logic.
      
      This speeds up Object.prototype.isPrototypeOf by more than a factor of
      four, so that the code
      
        A.prototype.isPrototypeOf(a)
      
      is now performance-wise on par with
      
        a instanceof A
      
      for the case where A is a regular constructor function and a is an
      instance of A.
      
      Since instanceof does more than just the fundamental prototype chain
      lookup, it was discovered in Node core that O.p.isPrototypeOf would
      be a more appropriate alternative for certain sanity checks, since
      it's less vulnerable to monkey-patching. In addition, the Object
      builtin would also avoid the performance-cliff associated with
      instanceof (due to the Symbol.hasInstance hook), as for example hit
      by https://github.com/nodejs/node/pull/13403#issuecomment-305915874.
      The main blocker was the missing performance of isPrototypeOf, since
      it was still a JS builtin backed by a runtime call.
      
      This CL also adds more test coverage for the
      Object.prototype.isPrototypeOf builtin, especially when called from
      optimized code.
      
      CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
      BUG=v8:5269,v8:5989,v8:6483
      R=jgruber@chromium.org
      
      Review-Url: https://codereview.chromium.org/2934893002
      Cr-Commit-Position: refs/heads/master@{#45925}
      b11c557d
  9. 12 Jun, 2017 1 commit
  10. 08 Jun, 2017 1 commit
    • Ross McIlroy's avatar
      [TurboFan] Add typing for the EmptyString and use this for JSToPrimitiveToString · 2c296b7e
      Ross McIlroy authored
      Add the ability for the typer to track whether a string could be the empty
      string. This is needed for typed lowering of JSStringConcat since we can't
      create cons string chain with the empty string in arbitrary positions.
      
      The ToPrimitiveToString bytecode handler is modified to collect feedback on
      whether it has ever seen the empty string, which is used by
      SpeculativeToPrimitiveToString to ensure that the output is non-empty (or
      depot) which will subsiquently be used to enable inline cons-string creation
      for the JSStringConcat operator in typed lowering in a subsiquent CL.
      
      BUG=v8:6243
      
      Change-Id: I41b99b59798993f756aada8cff90fb137d65ea52
      Reviewed-on: https://chromium-review.googlesource.com/522122
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45786}
      2c296b7e
  11. 07 Jun, 2017 1 commit
  12. 06 Jun, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Properly support Number feedback for binary operators. · 8a150262
      bmeurer authored
      Previously Ignition would collect precise Number feedback for binary
      operators, but TurboFan would just ignore that and treat it the same as
      NumberOrOddball. That however generates a lot of unnecessary code, plus
      it defeats redundancy elimination if the same input is also used by
      compare operations, which do properly distinguish feedback Number and
      NumberOrOddball.
      
      This CL adds the missing bits to connect the existing functionality
      properly, i.e. adding the missing BinaryOperationHint and using the
      NumberOperationHint::kNumber in the representation selection for tagged
      inputs.
      
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2923543003
      Cr-Commit-Position: refs/heads/master@{#45732}
      8a150262
  13. 31 May, 2017 1 commit
  14. 22 May, 2017 2 commits
  15. 18 May, 2017 2 commits
    • bmeurer's avatar
      [turbofan] Eliminate empty string addition. · cd1325a8
      bmeurer authored
      For additions like a+'' or ''+a where we have String feedback on the
      JSAdd, we can drop the concatenation and just check that a is a valid
      String already (via CheckString).
      
      BUG=v8:6259
      R=petermarshall@chromium.org
      
      Review-Url: https://codereview.chromium.org/2894563002
      Cr-Commit-Position: refs/heads/master@{#45395}
      cd1325a8
    • bmeurer's avatar
      [turbofan] Avoid allocating rest parameters for spread calls. · bfa319e5
      bmeurer authored
      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.
      
      BUG=v8:6407,v8:6278,v8:6344
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2890023004
      Cr-Commit-Position: refs/heads/master@{#45388}
      bfa319e5
  16. 04 May, 2017 2 commits
    • gdeepti's avatar
      [wasm] Avoid js-typed-lowering optimization for wasm Memory objects · 82503e9b
      gdeepti authored
      If an ArrayBuffer is setup through the WebAssembly.Memory constructor, identify these with a flag and avoid optimizations in js-typed-lowering.cc. This is needed becasue buffers associated with memory objects can be grown/detached leading to crashes.
      
      BUG=chromium:717194
      
      Review-Url: https://codereview.chromium.org/2862763002
      Cr-Commit-Position: refs/heads/master@{#45105}
      82503e9b
    • neis's avatar
      [compiler][modules] Constant-fold loads of module cells. · 24d78901
      neis authored
      1. Generalize context specialization such that the provided context
         can be any outer context of the function, not necessarily the
         immediate outer context.
      
      2. Based on this: if function specialization is disabled, then
         specialize for the module context if there is one.
      
      3. Extend typed lowering of module loads and stores such that if
         the operand is a Module constant, we constant-fold the cell load.
         That is, a JSLoadModule with a Module HeapConstant input becomes
         a LoadField with a Cell HeapConstant input, and similarly for
         JSStoreModule.
      
      BUG=v8:1569
      
      Review-Url: https://codereview.chromium.org/2841613002
      Cr-Commit-Position: refs/heads/master@{#45083}
      24d78901
  17. 03 May, 2017 1 commit
  18. 19 Apr, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Constant-fold certain JSOrdinaryHasInstance nodes. · c9c7dd0d
      bmeurer authored
      Move JSOrdinaryHasInstance lowering to JSNativeContextSpecialization,
      which was previously mostly done in JSTypedLowering (for no reason).
      Add new logic to the lowering to constant-fold OrdinaryHasInstance
      checks when the map of the left-hand side and the "prototype" of the
      right-hand side is known. This address the performance issue with the
      (base) class constructors generated by Babel, i.e.:
      
        function _classCallCheck(instance, Constructor) {
          if (!(instance instanceof Constructor)) {
            throw new TypeError("Cannot call a class as a function");
          }
        }
      
        var C = function C() { _classCallCheck(this, C); };
      
      for
      
        class C {}
      
      Also ensure that a known constructor being used inside an instanceof
      get's a proper initial map on-demand.
      
      BUG=v8:6275
      R=mstarzinger@chromium.org
      
      Review-Url: https://codereview.chromium.org/2827013002
      Cr-Commit-Position: refs/heads/master@{#44727}
      c9c7dd0d
  19. 07 Apr, 2017 1 commit
    • jarin's avatar
      [turbofan] Add type to the allocation operator. · e97b29a4
      jarin authored
      This gives us more precise type information, so we can avoid some type
      guards to refine the type information back.
      
      The motivation for this is to help escape analysis by not introducing
      redundant type guards (which escape analysis cannot handle yet even
      though it could and should do).
      
      Motivating example:
      
      In the example below, the out-of-object property array for properties
      fld5 and fld6 gets type Any when it is created by "o.fld5 = 5" (for
      object literals, we store 4 properties in-objeca, the rest goes out
      of object).
      
      When we run load elimination for the load the out-of-object property
      array (to store 6 into o.fld6), load elimination inserts TypeGuard to
      enforce the Type::Internal() type. This makes escape analysis bail out
      on this object, and we do not eliminate the object creation.
      
      function f() {
        var o = {};
        o.fld1 = 1;
        o.fld2 = 2;
        o.fld3 = 3;
        o.fld4 = 4;
        o.fld5 = 5;
        o.fld6 = 6;
      }
      
      f();
      f();
      %OptimizeFunctionOnNextCall(f);
      f();
      
      Review-Url: https://codereview.chromium.org/2797993006
      Cr-Commit-Position: refs/heads/master@{#44470}
      e97b29a4
  20. 29 Mar, 2017 2 commits
    • 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
    • bmeurer's avatar
      [turbofan] Remove typeof optimization from typed lowering. · 0554e36b
      bmeurer authored
      Now that Ignition has the dedicated TestTypeOf operator, there's not
      really a point in doing the typeof with abstract/strict equal combining
      in TurboFan anymore. In fact it's counter-productive to do so, as it
      might try to cover typeof comparisons in cases where it's better to just
      compute the typeof once, i.e.:
      
        let x = typeof a, y = typeof b;
        if (x === y) {
          if (x === 'string') {
            ...
          }
        }
      
      Here we would combine the second comparison into an ObjectIsString, and
      still compute the typeof a.
      
      R=jarin@chromium.org
      BUG=v8:5267
      
      Review-Url: https://codereview.chromium.org/2780953003
      Cr-Commit-Position: refs/heads/master@{#44220}
      0554e36b
  21. 20 Mar, 2017 1 commit
  22. 15 Mar, 2017 2 commits
  23. 14 Mar, 2017 1 commit
  24. 07 Mar, 2017 1 commit
  25. 03 Mar, 2017 2 commits
  26. 28 Feb, 2017 1 commit
  27. 27 Feb, 2017 1 commit
  28. 23 Feb, 2017 1 commit
  29. 22 Feb, 2017 2 commits
  30. 20 Feb, 2017 2 commits
  31. 18 Feb, 2017 1 commit
    • vabr's avatar
      Fix typeof optimization for undetectable · 6302753e
      vabr authored
      Currently, typeof o, where o is an undetectable
      callable object (such as document.all), returns 'function' if
      optimised. It should, however, return 'undefined'.
      
      This CL excludes undetectable objects from the optimization
      resulting in type 'function' and renames the related code to
      reflect that.
      
      BUG=v8:5972
      R=bmeurer@chromium.org
      
      Review-Url: https://codereview.chromium.org/2697063002
      Cr-Commit-Position: refs/heads/master@{#43298}
      6302753e
  32. 16 Feb, 2017 1 commit