1. 27 May, 2019 1 commit
    • Georg Schmid's avatar
      Reland "Make LoadElimination aware of const fields (Part 2; stores)" · 85f257f4
      Georg Schmid authored
      This is a reland of e588ff10
      
      The only change over the original CL is found in JSCreateLowering::AllocateFastLiteral. We now guard against boilerplate values for unboxed double fields that *look* like legitimate initial values, but should really be kHoleNanInt64 instead.
      
      The underlying problem certainly existed before, but an invariant added to LoadElimination in this CL caused a Chromium layout test to fail. The change in this reland is therefore a workaround, the root cause remains to be fixed. Specifically, we find that a pointer to the undefined value oddball is sometimes reinterpreted as a double and assigned as a boilerplate value. @jarin suspects that this stems from in-place map updates.
      
      Original change's description:
      > Make LoadElimination aware of const fields (Part 2; stores)
      >
      > Adds const information to store field accesses and uses it in load elimination
      >
      > Change-Id: I00765c854c95c955dabd78557463267b95f75eef
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611543
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Commit-Queue: Georg Schmid <gsps@google.com>
      > Cr-Commit-Position: refs/heads/master@{#61796}
      
      Change-Id: Ie388754890024a3ca7d10c9d4d7391442655b426
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1630676Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Georg Schmid <gsps@google.com>
      Cr-Commit-Position: refs/heads/master@{#61838}
      85f257f4
  2. 24 May, 2019 1 commit
  3. 23 May, 2019 3 commits
  4. 15 May, 2019 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Use CheckHeapObject only for StoreField. · c7ca8dac
      Benedikt Meurer authored
      Previously we had to use CheckHeapObject in front of every CheckMaps,
      CompareMaps and TransitionElementsKind operation. Now these operators
      request HeapObject representation themselves (requiring for CompareMaps
      and TransitionElementsKind to remove the kNoDeopt property). This means
      we only do CheckHeapObject for StoreField to a field that has HeapObject
      representation.
      
      This not only leads to smaller graphs in the compiler, but also removes
      most uses of the CheckHeapObject operator, which doesn't express a real
      semantic property in the compiler frontend.
      
      Bug: v8:9183, v8:9250
      Refs: nodejs/node#27667
      Change-Id: Ie3d83de69583b1bed6c1c53444bfc97aaef624bb
      Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1612902Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61508}
      c7ca8dac
  5. 14 May, 2019 1 commit
    • Benedikt Meurer's avatar
      [dataview] Introduce JSDataView::data_pointer field. · 4ef714a6
      Benedikt Meurer authored
      This is a preparation for doing a similar change to JSTypedArrays to
      be able to finally access huge ArrayBuffers with TypedArrays. This CL
      itself improves the performance of DataViews, sometimes to be even
      faster than TypedArrays now. On the test case[1] we go from
      
        testDataViewGetUint8: 711 ms.
        testUint8Array: 654 ms.
        testDataViewGetUint16: 801 ms.
        testUint16Array: 649 ms.
        testDataViewGetInt32: 699 ms.
        testInt32Array: 648 ms.
        testDataViewGetFloat64: 701 ms.
        testFloat64Array: 650 ms.
      
      to
      
        testDataViewGetUint8: 622 ms.
        testUint8Array: 656 ms.
        testDataViewGetUint16: 634 ms.
        testUint16Array: 656 ms.
        testDataViewGetInt32: 629 ms.
        testInt32Array: 655 ms.
        testDataViewGetFloat64: 631 ms.
        testFloat64Array: 661 ms.
      
      so the performance improves by up to **20%**.
      
      [1] https://github.com/bmeurer/js-micro-benchmarks/blob/master/bench-dataview.js
      
      Tbr: ulan@chromium.org
      Bug: chromium:225811, v8:4153, v8:8383
      Change-Id: Ie4409e2fe96e5085ddcf5eb3f24f3cacfb3afe02
      Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1601144
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61464}
      4ef714a6
  6. 09 May, 2019 1 commit
  7. 08 May, 2019 1 commit
  8. 24 Apr, 2019 1 commit
    • Tobias Tebbi's avatar
      [csa][turbofan] allow large object allocation · 343898ed
      Tobias Tebbi authored
      Add suport for large object space allocations in Turbofan and use it
      from CSA when young large objects are enabled. This maintains the
      Turbofan invariant that the generation is statically predictable.
      
      In principle, this enables write barrier elimination for large objects
      allocated from Torque/CSA. But it doesn't seem to trigger much yet,
      probably we have to improve the MemoryOptimizer.
      
      Bug: v8:7793
      
      Change-Id: I7ea7d0cb549573db65fafe5df5edf67e0ce90893
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1565905Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60984}
      343898ed
  9. 18 Apr, 2019 2 commits
  10. 11 Apr, 2019 1 commit
  11. 03 Apr, 2019 1 commit
  12. 19 Mar, 2019 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Significantly improve ConsString creation performance. · d6a60a0e
      Benedikt Meurer authored
      This change significantly improves the performance of string
      concatenation in optimized code for the case where the resulting string
      is represented as a ConsString. On the relevant test cases we go from
      
        serializeNaive: 10762 ms.
        serializeClever: 7813 ms.
        serializeConcat: 10271 ms.
      
      to
      
        serializeNaive: 10278 ms.
        serializeClever: 5533 ms.
        serializeConcat: 10310 ms.
      
      which represents a 30% improvement on the "clever" benchmark, which
      tests specifically the ConsString creation performance.
      
      This was accomplished via a couple of different steps, which are briefly
      outlined here:
      
        1. The empty_string gets its own map, so that we can easily recognize
           and handle it appropriately in the TurboFan type system. This
           allows us to express (and assert) that the inputs to NewConsString
           are non-empty strings, making sure that TurboFan no longer creates
           "crippled ConsStrings" with empty left or right hand sides.
        2. Further split the existing String types in TurboFan to be able to
           distinguish between OneByte and TwoByte strings on the type system
           level. This allows us to avoid having to dynamically lookup the
           resulting ConsString map in case of ConsString creation (i.e. when
           we know that both input strings are OneByte strings or at least
           one of the input strings is TwoByte).
        3. We also introduced more finegrained feedback for the Add bytecode
           in the interpreter, having it collect feedback about ConsStrings,
           specifically ConsOneByteString and ConsTwoByteString. This feedback
           can be used by TurboFan to only inline the relevant code for what
           was seen so far. This allows us to remove the Octane/Splay specific
           magic in JSTypedLowering to detect ConsString creation, and instead
           purely rely on the feedback of what was seen so far (also making it
           possible to change the semantics of NewConsString to be a low-level
           operator, which is only introduced in SimplifiedLowering by looking
           at the input types of StringConcat).
        4. On top of the before mentioned type and interpreter changes we added
           new operators CheckNonEmptyString, CheckNonEmptyOneByteString, and
           CheckNonEmptyTwoByteString, which perform the appropriate (dynamic)
           checks.
      
      There are several more improvements that are possible based on this, but
      since the change was already quite big, we decided not to put everything
      into the first change, but do some follow up tweaks to the type system,
      and builtin optimizations later.
      
      Tbr: mstarzinger@chromium.org
      Bug: v8:8834, v8:8931, v8:8939, v8:8951
      Change-Id: Ia24e17c6048bf2b04df966d3cd441f0edda05c93
      Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
      Doc: https://bit.ly/fast-string-concatenation-in-javascript
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1499497
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60318}
      d6a60a0e
  13. 12 Mar, 2019 1 commit
  14. 25 Feb, 2019 2 commits
  15. 22 Feb, 2019 1 commit
  16. 13 Feb, 2019 1 commit
  17. 08 Feb, 2019 1 commit
  18. 31 Jan, 2019 1 commit
  19. 02 Jan, 2019 1 commit
  20. 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
  21. 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
  22. 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
  23. 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
  24. 05 Oct, 2018 1 commit
  25. 04 Oct, 2018 1 commit
  26. 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
  27. 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
  28. 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
  29. 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
  30. 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
  31. 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
  32. 05 Jul, 2018 1 commit
  33. 04 Jul, 2018 1 commit
  34. 29 May, 2018 1 commit