1. 22 Feb, 2019 1 commit
  2. 08 Feb, 2019 1 commit
  3. 31 Jan, 2019 1 commit
  4. 09 Nov, 2018 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Fix -0 check for subnormals. · 56f6a763
      Benedikt Meurer authored
      Previously we'd check `x` for -0 by testing `(1.0 / x) == -Infinity`,
      but this will yield the wrong results when `x` is a subnormal, i.e.
      really close to 0.
      
      In CSA we already perform bit checks to test for -0, so teach TurboFan
      to do the same for comparisons to -0 (via `Object.is`). We introduce a
      new NumberIsMinusZero simplified operator to handle the case where
      SimplifiedLowering already knows that the input is a number.
      
      Bug: chromium:903043, v8:6882
      Change-Id: I0cb7c568029b461a92fc183104d5f359b4bfe7f4
      Reviewed-on: https://chromium-review.googlesource.com/c/1328802
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57382}
      56f6a763
  5. 29 Oct, 2018 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Add support for huge DataViews. · 15c31fe4
      Benedikt Meurer authored
      This introduces Word64 support for the CheckBounds operator, which now
      lowers to either CheckedUint32Bounds or CheckedUint64Bounds after the
      representation selection. The right hand side of CheckBounds can now
      be any positive safe integer on 64-bit architectures, whereas it remains
      Unsigned31 for 32-bit architectures. We only use the extended Word64
      support when the right hand side is outside the Unsigned31 range, so
      for everything except DataViews this means that the performance should
      remain the same. The typing rule for the CheckBounds operator was
      updated to reflect this new behavior.
      
      The CheckBounds with a right hand side outside the Unsigned31 range will
      pass a new Signed64 feedback kind, which is handled with newly introduced
      CheckedFloat64ToInt64 and CheckedTaggedToInt64 operators in representation
      selection.
      
      The JSCallReducer lowering for DataView getType()/setType() methods was
      updated to not smi-check the [[ByteLength]] and [[ByteOffset]] anymore,
      but instead just use the raw uintptr_t values and operate on any value
      (for 64-bit architectures these fields can hold any positive safe
      integer, for 32-bit architectures it's limited to Unsigned31 range as
      before). This means that V8 can now handle huge DataViews fully, without
      falling off a performance cliff.
      
      This refactoring even gave us some performance improvements, on a simple
      micro-benchmark just exercising different DataView accesses we go from
      
        testDataViewGetUint8: 796 ms.
        testDataViewGetUint16: 997 ms.
        testDataViewGetInt32: 994 ms.
        testDataViewGetFloat64: 997 ms.
      
      to
      
        testDataViewGetUint8: 895 ms.
        testDataViewGetUint16: 889 ms.
        testDataViewGetInt32: 888 ms.
        testDataViewGetFloat64: 890 ms.
      
      meaning we lost around 10% on the single byte case, but gained 10% across
      the board for all the other element sizes.
      
      Design-Document: http://bit.ly/turbofan-word64
      Bug: chromium:225811, v8:4153, v8:7881, v8:8171, v8:8383
      Change-Id: Ic9d1bf152e47802c04dcfd679372e5c85e4abc83
      Reviewed-on: https://chromium-review.googlesource.com/c/1303732Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57095}
      15c31fe4
  6. 24 Oct, 2018 2 commits
    • Benedikt Meurer's avatar
      [turbofan] ReceiverOrNullOrUndefined feedback for JSEqual. · f19c4a59
      Benedikt Meurer authored
      This changes the ReceiverOrOddball feedback on JSStrictEqual to
      ReceiverOrNullOrUndefined feedback, which can also safely be
      consumed by JSEqual (we cannot generally accept any oddball here
      since booleans trigger implicit conversions, unfortunately).
      Thus we replace the previously introduced CheckReceiverOrOddball
      with CheckReceiverOrNullOrUndefined, and drop CheckOddball, since
      we will no longer collect Oddball feedback separately.
      
      TurboFan will then turn a JSEqual[ReceiverOrNullOrUndefined] into
      a sequence like this:
      
      ```
      left = CheckReceiverOrNullOrUndefined(left);
      right = CheckReceiverOrNullOrUndefined(right);
      result = if ObjectIsUndetectable(left) then
                 ObjectIsUndetectable(right)
               else
                 ReferenceEqual(left, right);
      ```
      
      This significantly improves the peak performance of abstract equality
      with Receiver, Null or Undefined inputs. On the test case outlined in
      http://crbug.com/v8/8356 we go from
      
        naive: 2946 ms.
        tenary: 2134 ms.
      
      to
      
        naive: 2230 ms.
        tenary: 2250 ms.
      
      which corresponds to a 25% improvement on the abstract equality case.
      For regular code this will probably yield more performance, since we
      get rid of the JSEqual operator, which might have arbitrary side
      effects and thus blocks all kinds of TurboFan optimizations. The
      JSStrictEqual case is slightly slower now, since it has to rule out
      booleans as well (even though that's not strictly necessary, but
      consistency is key here).
      
      This way developers can safely use `a == b` instead of doing a dance
      like `a == null ? b == null : a === b` (which is what dart2js does
      right now) when both `a` and `b` are known to be Receiver, Null or
      Undefined. The abstract equality is not only faster to parse than
      the tenary, but also generates a shorter bytecode sequence. In the
      test case referenced in http://crbug.com/v8/8356 the bytecode for
      `naive` is
      
      ```
      StackCheck
      Ldar a1
      TestEqual a0, [0]
      JumpIfFalse [5]
      LdaSmi [1]
      Return
      LdaSmi [2]
      Return
      ```
      
      which is 14 bytes, whereas the `tenary` function generates
      
      ```
      StackCheck
      Ldar a0
      TestUndetectable
      JumpIfFalse [7]
      Ldar a1
      TestUndetectable
      Jump [7]
      Ldar a1
      TestEqualStrict a0, [0]
      JumpIfToBooleanFalse [5]
      LdaSmi [1]
      Return
      LdaSmi [2]
      Return
      ```
      
      which is 24 bytes. So the `naive` version is 40% smaller and requires
      fewer bytecode dispatches.
      
      Bug: chromium:898455, v8:8356
      Change-Id: If3961b2518b4438700706b3bd6071d546305e233
      Reviewed-on: https://chromium-review.googlesource.com/c/1297315Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56948}
      f19c4a59
    • Benedikt Meurer's avatar
      [turbofan] Collect and consume (ReceiverOr)Oddball feedback for StrictEqual. · 8f00d61d
      Benedikt Meurer authored
      This CL introduces proper Oddball and ReceiverOrOddball states for the
      CompareOperationFeedback, and updates the StrictEqual IC to collect this
      feedback as well. Previously it would not collect Oddball feedback, not
      even in the sense of NumberOrOddball, since that's not usable for the
      SpeculativeNumberEqual.
      
      The new feedback is handled via newly introduced CheckReceiverOrOddball
      and CheckOddball operators in TurboFan, introduced by JSTypedLowering.
      Just like with the Receiver feedback, it's enough to check one side and
      do a ReferenceEqual afterwards, since strict equal can only yield true
      if both sides refer to the same instance.
      
      This improves the benchmark mentioned in http://crbug.com/v8/8356 from
      
        naive: 2950 ms.
        tenary: 2456 ms.
      
      to around
      
        naive: 2996 ms.
        tenary: 2192 ms.
      
      which corresponds to a roughly 10% improvement in the case for the
      tenary pattern, which is currently used by dart2js. In real world
      scenarios this will probably help even more, since TurboFan is able
      to optimize across the strict equality, i.e. there's no longer a stub
      call forcibly spilling all registers that are live across the call.
      
      This new feedback will be used as a basis for the JSEqual support for
      ReceiverOrOddball, which will allow dart2js switching to the shorter
      a==b form, at the same peak performance.
      
      Bug: v8:8356
      Change-Id: Iafbf5d64fcc9312f9e575b54c32c631ce9b572b2
      Reviewed-on: https://chromium-review.googlesource.com/c/1297309Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56925}
      8f00d61d
  7. 07 Oct, 2018 1 commit
    • Benedikt Meurer's avatar
      Revert "[turbofan] Do not consume SignedSmall feedback in TurboFan anymore." · 248fd5ff
      Benedikt Meurer authored
      This reverts commit 4fd92b25.
      
      Reason for revert: Significant tankage on the no-mitigations bots (bad timing on the regular bots)
      
      Original change's description:
      > [turbofan] Do not consume SignedSmall feedback in TurboFan anymore.
      > 
      > This changes TurboFan to treat SignedSmall feedback similar to Signed32
      > feedback for binary and compare operations, in order to simplify and
      > unify the machinery.
      > 
      > This is an experiment. If this turns out to tank performance, we will
      > need to revisit and ideally revert this change.
      > 
      > Bug: v8:7094
      > Change-Id: I885769c2fe93d8413e59838fbe844650c848c3f1
      > Reviewed-on: https://chromium-review.googlesource.com/c/1261442
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#56411}
      
      TBR=jarin@chromium.org,bmeurer@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:7094
      Change-Id: I9fff3b40e6dc0ceb7611b55e1ca9940089470404
      Reviewed-on: https://chromium-review.googlesource.com/c/1267175Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56427}
      248fd5ff
  8. 05 Oct, 2018 1 commit
  9. 19 Sep, 2018 1 commit
  10. 17 Sep, 2018 2 commits
    • Benedikt Meurer's avatar
      [cleanup] Cleanup JSArrayBuffer and TurboFan's handling of neutering. · beebb236
      Benedikt Meurer authored
      Cleanup the JSArrayBuffer bit fields to use the proper object macros
      that are now otherwise used consistently across the code base. Also
      change TurboFan to consistently bailout when it sees an array buffer
      that was previously neutered, so that the generic path / builtins are
      again the chokepoints for the spec violations (the fact that we don't
      always raise exceptions when we see a neutered array buffer), except
      for the ArrayBufferView accessor inlining in the JSCallReducer, where
      we still turn the values into zero (because we don't have access to
      a CALL_IC speculation guard in the common case).
      
      This also removes the ArrayBufferWasNeutered simplified operator, and
      does regular LoadField + Number bitwise operations instead, which is
      good enough and allows us to get rid of a lot of unnecessary complexity.
      
      Bug: v8:4153, v8:7881, v8:8015, v8:8171, v8:8178
      Change-Id: I4ce79ece762c632e6318f2ab7bcc6b2f82383947
      Reviewed-on: https://chromium-review.googlesource.com/1226887Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55958}
      beebb236
    • Benedikt Meurer's avatar
      [turbofan] Initial support to compute NumberAdd/NumberSubtract in Word64. · 0c296cb2
      Benedikt Meurer authored
      This change introduces the necessary conversion operators to convert
      from Word64 to other representations (Tagged, Word32, Float64, etc.),
      and plugs in the Word64 representation for NumberAdd/NumberSubtract,
      such that TurboFan will go to Int64Add/Sub on 64-bit architectures
      when the inputs and the output of the operation is in safe integer
      range. This includes the necessary changes to the Deoptimizer to be
      able to rematerialize Int64 values as Smi/HeapNumber when going back
      to Ignition later.
      
      This change might affect performance, although measurements indicate
      that there should be no noticable performance impact.
      
      The goal is to have TurboFan support Word64 representation to a degree
      that changing the TypedArray length to an uint64_t (for 64-bit archs)
      becomes viable and doesn't have any negative performance implications.
      Independent of that we might get performance improvements in other areas
      such as for crypto code later.
      
      Bug: v8:4153, v8:7881, v8:8171, v8:8178
      Design-Document: bit.ly/turbofan-word64
      Change-Id: I29d56e2a31c1bae61d04a89d29ea73f21fd49c59
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel
      Reviewed-on: https://chromium-review.googlesource.com/1225709
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55937}
      0c296cb2
  11. 14 Sep, 2018 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Initial Word64 support in representation selection. · 6346cdb6
      Benedikt Meurer authored
      This adds support to TurboFan's representation selection for the Word64
      representation, and makes use of that to handle indices for memory access
      and allocation instructions (i.e. LoadElement, StoreElement, Allocate,
      etc.). These instructions had previously used Word32 as representation
      for the indices / sizes, and then internally converted it to the correct
      representation (aka Word64 on 64-bit architectures) later on, but that
      was kind of brittle, and sometimes led to weird generated code.
      
      The change thus only adds support to convert integer values in the safe
      integer range from all kinds of representations to Word64 (on 64-bit
      architectures). We don't yet handle the opposite direction and none of
      the representation selection heuristics for the numeric operations were
      changed so far. This will be done in follow-up CLs.
      
      This CL itself is supposed to be neutral wrt. functionality, and only
      serves as a starting point, and a cleanup for the (weird) implicit
      Word64 index/size handling.
      
      Bug: v8:7881, v8:8015, v8:8171
      Design-Document: http://bit.ly/turbofan-word64
      Change-Id: I3c6961a0e96cbc3fb8ac9d3e1be8f2e5c89bfd25
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel
      Reviewed-on: https://chromium-review.googlesource.com/1224932
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55886}
      6346cdb6
  12. 07 Sep, 2018 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Introduce a pure StringConcat operator. · e56b6d24
      Benedikt Meurer authored
      This replaces the previous CheckStringAdd operator which deopts in case
      the combined length overflows with a dedicated pure StringConcat operator.
      This operator is similar to NewConsString in that it takes the resulting
      length plus the two input strings. The operator relies on the length
      being checked explicitly by the surrounding code instead of baking the
      check into the operator itself. This way TurboFan can eliminate
      redundant/unnecessary StringConcat operations, since they are pure now.
      
      This also unifies the treatment of string addition in JSTypedLowering,
      and generalizes the StringLength constant-folding to apply to more cases
      not just the JSAdd cases inside JSTypedLowering.
      
      Bug: v8:7902, v8:8015
      Change-Id: I987ec39815a9464fd5fd9c4f7b26b709f94f2b3f
      Reviewed-on: https://chromium-review.googlesource.com/1213205Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55725}
      e56b6d24
  13. 29 Aug, 2018 1 commit
    • Maya Lekova's avatar
      [turbofan] Introduce a CheckStringAdd node instead of cons string lowering · 6a7872b7
      Maya Lekova authored
      The new node is introduced for literal string addition and calling
      String.prototype.concat in the typed lowering phase. It later might get optimized
      away during redundancy elimination, keeping the performance of already existing
      benchmarks with string addition. In case the operation is about to throw
      (due to too long string being constructed) we just deoptimize, reusing
      the interpreter logic for creating the error.
      
      Modify relevant mjsunit and unit tests for string concatenation.
      
      Bug: v8:7902
      Change-Id: Ie97d39534df4480fa8d4fe3ba276d02ed5e750e3
      Reviewed-on: https://chromium-review.googlesource.com/1193342
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55482}
      6a7872b7
  14. 24 Aug, 2018 1 commit
  15. 22 Aug, 2018 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Support HOLEY_DOUBLE_ELEMENTS for Array#find() and findIndex(). · 11261f42
      Benedikt Meurer authored
      This adds the missing support for HOLEY_DOUBLE_ELEMENTS to both
      `Array#find()` and `Array#findIndex()`. The implementation just deopts
      whenever it hits a double hole. In order to prevent deoptimization
      loops we add feedback to the CheckFloat64Hole operator, which also
      addresses the TODO in the `%ArrayIteratorPrototype%.next()` lowering.
      
      This provides a speed-up of up to 8x in microbenchmarks when using
      `Array#find()` or `Array#findIndex()` on HOLEY_DOUBLE_ELEMENTS arrays.
      
      Bug: chromium:791045, v8:1956, v8:6587, v8:7165, v8:8015
      Change-Id: I1be22d3fcba56c676a81dc31a9042f8123ef3a55
      Reviewed-on: https://chromium-review.googlesource.com/1183906Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55321}
      11261f42
  16. 23 Jul, 2018 1 commit
  17. 09 Jul, 2018 1 commit
    • Théotime Grohens's avatar
      [turbofan] Add DataView setters in TurboFan · c4323e08
      Théotime Grohens authored
      This CL completes the implementation of DataView prototype methods
      in TurboFan, by implementing the Uint8, Int8, Uint16, Int16,
      Uint32, Int32, Float32 and Float64 setters.
      
      DataView performance is now ahead of the equivalent TypedArray wrapper,
      and is now expected to at least match TypedArray performance in
      the general case as well.
      
      This CL also adds a test file in the compiler directory, to make
      sure that the setters actually behave correctly.
      
      Change-Id: I4ad4341c6b9b9d461348b62216f37a73abe321e8
      Reviewed-on: https://chromium-review.googlesource.com/1128867Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Théotime Grohens <theotime@google.com>
      Cr-Commit-Position: refs/heads/master@{#54331}
      c4323e08
  18. 04 Jul, 2018 1 commit
  19. 29 May, 2018 1 commit
  20. 16 May, 2018 1 commit
  21. 30 Apr, 2018 1 commit
    • Jaroslav Sevcik's avatar
      Replace array index masking with the poisoning approach. · f53dfd93
      Jaroslav Sevcik authored
      The idea is to mark all the branches and loads participating in array
      bounds checks, and let them contribute-to/use the poisoning register.
      In the code, the marks for array indexing operations now contain
      "Critical" in their name. By default (--untrusted-code-mitigations),
      we only instrument the "critical" operations with poisoning.
      
      With that in place, we also remove the array masking approach based
      on arithmetic.
      
      Since we do not propagate the poison through function calls,
      we introduce a node for poisoning an index that is passed through
      function call - the typical example is the bounds-checked index
      that is passed to the CharCodeAt builtin.
      
      Most of the code in this CL is threads through the three levels of
      protection (safe, critical, unsafe) for loads, branches and flags.
      
      Bug: chromium:798964
      
      Change-Id: Ief68e2329528277b3ba9156115b2a6dcc540d52b
      Reviewed-on: https://chromium-review.googlesource.com/995413
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52883}
      f53dfd93
  22. 28 Apr, 2018 1 commit
  23. 25 Apr, 2018 1 commit
  24. 23 Apr, 2018 1 commit
  25. 06 Apr, 2018 1 commit
  26. 23 Mar, 2018 2 commits
  27. 21 Mar, 2018 2 commits
  28. 20 Mar, 2018 1 commit
  29. 16 Mar, 2018 3 commits
  30. 12 Mar, 2018 1 commit
  31. 05 Mar, 2018 1 commit
  32. 23 Feb, 2018 1 commit
  33. 15 Feb, 2018 1 commit
  34. 08 Feb, 2018 1 commit