1. 24 Jun, 2020 1 commit
  2. 28 May, 2020 1 commit
    • Nico Hartmann's avatar
      Reland "[turbofan] Improve equality on NumberOrOddball" · 120d4333
      Nico Hartmann authored
      This is a reland of 6204768b
      
      The original issue exposed the problem that NumberEqual performs
      implicit conversion of oddballs to numbers, which is incorrect for
      abstract equality comparison (i.e. 0 == null must not be true).
      
      This reland fixes this by applying the following steps:
      * Introduced a new kNumberOrBoolean value for CompareOperationFeedback,
        CompareOperationHint, TypeCheckKind and CheckedTaggedInputMode.
      * In CodeStubAssembler::Equal: Further distinguish between boolean and
        non-boolean oddballs and set feedback accoringly.
      * In JSTypedLowering: Construct [Speculative]NumberEqual operator with
        CompareOperationHint::kNumberOrBoolean, when this feedback is present.
        JSOperatorBuilder and operator cache are extended accordingly.
      * In SimplifiedLowering: Propagate a UseInfo with new
        TypeCheckKind::kNumberOrBoolean.
      * This leads to the generation of CheckedTaggedToFloat64 in
        RepresentationChanger with new CheckedTaggedInputMode::kNumberOrBoolean.
      * In EffectControlLinearizer: Handle this new mode. Accept and convert
        number and boolean and deopt for rest.
      
      Original change's description:
      > [turbofan] Improve equality on NumberOrOddball
      >
      > This CL cleans up CompareOperationFeedback by replacing it with a
      > composable set of flags. The interpreter is changed to collect
      > more specific feedback for abstract equality, especially if oddballs
      > are involved.
      >
      > TurboFan is changed to construct SpeculativeNumberEqual operator
      > instead of the generic JSEqual in many more cases. This change has
      > shown a local speedup of a factor of 3-10, because the specific
      > operator is way faster than calling into the generic builtin, but
      > it also enables additional optimizations, further improving
      > runtime performance.
      >
      > Bug: v8:5660
      > Change-Id: I856752caa707e9a4f742c6e7a9c75552fb431d28
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2162854
      > Reviewed-by: Mythri Alle <mythria@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67645}
      
      TBR: tebbi@chromium.org
      Bug: v8:5660
      Change-Id: I12e733149a1d2773cafb781a1d4b10aa1eb242a7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2193713
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68037}
      120d4333
  3. 21 Feb, 2020 1 commit
  4. 19 Feb, 2020 2 commits
  5. 18 Feb, 2020 2 commits
  6. 20 Nov, 2019 1 commit
  7. 11 Nov, 2019 1 commit
  8. 16 Oct, 2019 1 commit
  9. 19 Sep, 2019 1 commit
    • Clemens Hammacher's avatar
      Revert "[ptr-compr] Make on-heap JSTypedArrays smi-corrupting friendly" · 815df7d2
      Clemens Hammacher authored
      This reverts commit 6f9b2bd4.
      
      Reason for revert: Fails on nvidia bots, blocking LKGR: https://ci.chromium.org/p/v8/builders/ci/Win%20V8%20FYI%20Release%20(NVIDIA)/5005
      
      Original change's description:
      > [ptr-compr] Make on-heap JSTypedArrays smi-corrupting friendly
      > 
      > On-heap typed arrays contain HeapObject value in |base_pointer| field
      > and an offset in |external_pointer| field. When pointer compression is
      > enabled we want to combine decompression with the offset addition.
      > In order to do that we add an isolate root to the external_pointer value
      > and therefore the data pointer computation can is a simple addition of
      > a (potentially sign-extended) |base_pointer| loaded as Tagged_t value
      > and an |external_pointer| value.
      > 
      > Bug: v8:9706
      > Change-Id: Id5c546c353c81fb25e3598921bc78165d10a9c44
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807369
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Igor Sheludko <ishell@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63874}
      
      TBR=ulan@chromium.org,neis@chromium.org,jgruber@chromium.org,ishell@chromium.org,verwaest@chromium.org
      
      Change-Id: I901280dd191e78d02969600f775c4f0da796921f
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9706
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813027Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63886}
      815df7d2
  10. 18 Sep, 2019 1 commit
  11. 26 Aug, 2019 1 commit
  12. 23 Aug, 2019 2 commits
  13. 12 Aug, 2019 1 commit
  14. 09 Aug, 2019 1 commit
  15. 24 Jul, 2019 1 commit
  16. 12 Jul, 2019 1 commit
    • Nico Hartmann's avatar
      [turbofan] Push BigInt truncation over addition and heap constants · 99df710d
      Nico Hartmann authored
      This change implements lowering of speculative BigInt addition as well as
      BigInt heap constants to corresponding int64 versions, if they are used in
      a context where the result is truncated to the least significant 64 bits
      (e.g. using asUintN). The JSHeapBroker is extended to provide access to the
      BigInt's least significant digit during concurrent compilation. The BigInt
      context (required to introduce correct conversions) is recognized in the
      RepresentationChanger by either the output type propagated downward or the
      TypeCheckKind propagated upward. This is necessary, because the TypeCheckKind
      may only be set by nodes that may potentially deopt (and sit in the effect
      chain). This is the case for SpeculativeBigIntAdd, but not for BigIntAsUintN.
      
      This CL contains a simple fix to prevent int64-lowered BigInts to flow into
      state values as the deoptimizer cannot handle them yet. A more sophisticated
      solution to allow the deoptimizer to materialize truncated BigInts will be
      added in a following CL.
      
      Bug: v8:9407
      Change-Id: I96a293e9077962f53e5f199857644f004e3ae56e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1684183
      Commit-Queue: Nico Hartmann <nicohartmann@google.com>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62665}
      99df710d
  17. 02 Jul, 2019 1 commit
  18. 26 Jun, 2019 1 commit
  19. 25 Jun, 2019 2 commits
  20. 31 May, 2019 1 commit
  21. 22 May, 2019 1 commit
  22. 12 Apr, 2019 1 commit
  23. 03 Apr, 2019 1 commit
  24. 01 Apr, 2019 1 commit
  25. 26 Feb, 2019 1 commit
  26. 02 Jan, 2019 1 commit
  27. 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
  28. 01 Oct, 2018 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Unify handling of zeros. · 8ead5698
      Benedikt Meurer authored
      Following up on the earlier work regarding redundant Smi checks in
      https://chromium-review.googlesource.com/c/v8/v8/+/1246181, it was
      noticed that the handling of the 0 and -0 and how some operations
      identify these is not really consistent, but was still rather ad-hoc.
      This change tries to unify the handling a bit by making sure that all
      number comparisons generally pass truncations that identify zeros, since
      for the number comparisons in JavaScript there's no difference between
      0 and -0. In the same spirit NumberAbs and NumberToBoolean should also
      pass these truncations, since they also don't care about the differences
      between 0 and -0.
      
      Adjust NumberCeil, NumberFloor, NumberTrunc, NumberMin and NumberMax
      to pass along any incoming kIdentifiesZeros truncation, since these
      operations also don't really care whether the inputs can be -0 if the
      use nodes don't care.
      
      Also utilize the kIdentifiesZeros truncation for NumberModulus with
      Signed32 inputs, because it's kind of common to do something like
      `x % 2 === 0`, where it doesn't really matter whether `x % 2` would
      eventually produce a negative zero (since that would still be considered
      true for the sake of the comparison).
      
      This also adds a whole lot of tests to ensure that not only are these
      optimizations correct, but also that we do indeed perform them.
      
      Drive-by-fix: The `NumberAbs(x)` would incorrectly lower to just `x` for
      PositiveIntegerOrMinusZeroOrNaN inputs, which was obviously wrong in
      case of -0. This was fixed as well, and an appropriate test was added.
      
      The reason for the unification is that with the introduction of Word64
      for CheckBounds (which is necessary to support large TypedArrays and
      DataViews) we can no longer safely pass Word32 truncations for the
      interesting cases, since the index might be outside the Signed32 or
      Unsigned32 ranges, but we still identify 0 and -0 for the sake of the
      bounds check, and so it's important that this is handled consistently
      to not regress performance on TypedArrays and DataViews accesses.
      
      Bug: v8:8015, v8:8178
      Change-Id: Ia1d32f1b726754cea1e5793105d9423d84a6393a
      Reviewed-on: https://chromium-review.googlesource.com/1246172Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56325}
      8ead5698
  29. 17 Sep, 2018 1 commit
    • 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
  30. 14 Sep, 2018 2 commits
    • 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
    • Benedikt Meurer's avatar
      [turbofan] Remove Truncation::Word64(). · 52fc1552
      Benedikt Meurer authored
      This truncation doesn't have a proper meaning anyways and has never been
      used inside the representation selection. For pointer fields we also
      don't need to pass on a truncation anyways.
      
      Bug: v8:8015
      Change-Id: I5ff49e20b70fa70d6bcf7401a357cd7ad9f1a938
      Reviewed-on: https://chromium-review.googlesource.com/1226870
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55885}
      52fc1552
  31. 11 Sep, 2018 1 commit
    • Jaroslav Sevcik's avatar
      [turbofan] Insert unreachable node after unconditional deopt. · 3cfaca63
      Jaroslav Sevcik authored
      This inserts unreachable node after uncoditional deopt in bit-to-word
      conversion and wires it as an input to the dead-value.
      
      This fixes a problem, where a floating  dead-value was inserted by a change
      of bit-to-word (which always fails because bit cannot be converted to word).
      Without the unrachable node (which this CL inserts in the effect chain after
      deopt), the dead value was scheduled before the uncoditional deoptimization
      and crash at runtime.
      
      Unfortunately, I do not know how to construct a test that does not end up in
      an infinite loop.
      
      Bug: chromium:878805
      Change-Id: Ia03060949f6a9b914807f5614fadcf2271911998
      Reviewed-on: https://chromium-review.googlesource.com/1196663Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55770}
      3cfaca63
  32. 14 May, 2018 1 commit
  33. 28 Apr, 2018 1 commit
  34. 08 Feb, 2018 1 commit
  35. 23 Jan, 2018 1 commit