1. 28 Oct, 2021 1 commit
    • Tobias Tebbi's avatar
      Reland "[turbofan] extend type asserts to cover all JS types" · 392078fb
      Tobias Tebbi authored
      This is a reland of 45227ffd
      Differences:
      - Handle one more flags conflict in variants.py.
      - Disallow %VerifyType without --concurrent-recompilation.
      
      Original change's description:
      > [turbofan] extend type asserts to cover all JS types
      >
      > Extend type assertions to all types covering JavaScript values.
      > This is achieved by allocating type representations on the heap using
      > newly defined HeapObject subclasses. To allocate these in the compiler,
      > we disable concurrent compilation for the --assert-types flag for now.
      >
      > Fix two type errors that came up with the existing tests:
      > 1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of
      >    OtherObject.
      > 2. OperationTyper::NumberToString(Type) can type the result as the
      >    HeapConstant Factory::zero_string(). However, NumberToString does
      >    not always produce this string. To avoid regressions, the CL keeps
      >    the HeapConstant type and changes the runtime and builtin code to
      >    always produce the canonical "0" string.
      >
      > A few tests were failing because they check for truncations to work
      > and prevent deoptimization. However, AssertType nodes destroy all
      > truncations (which is by design), so these tests are incompatible
      > and now disabled for the assert_types variant.
      >
      > Drive-by fix: a few minor Torque issues that came up.
      >
      > Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Reviewed-by: Omer Katz <omerkatz@chromium.org>
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#77565}
      
      Change-Id: I5b3c6745c6ad349ff8c2b199d9afdf0a9b5a7392
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3247035
      Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77596}
      392078fb
  2. 27 Oct, 2021 2 commits
    • Maya Lekova's avatar
      Revert "[turbofan] extend type asserts to cover all JS types" · 54f90462
      Maya Lekova authored
      This reverts commit 45227ffd.
      
      Reason for revert: Breaks on gc_stress mode, see https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/35988/overview
      
      Original change's description:
      > [turbofan] extend type asserts to cover all JS types
      >
      > Extend type assertions to all types covering JavaScript values.
      > This is achieved by allocating type representations on the heap using
      > newly defined HeapObject subclasses. To allocate these in the compiler,
      > we disable concurrent compilation for the --assert-types flag for now.
      >
      > Fix two type errors that came up with the existing tests:
      > 1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of
      >    OtherObject.
      > 2. OperationTyper::NumberToString(Type) can type the result as the
      >    HeapConstant Factory::zero_string(). However, NumberToString does
      >    not always produce this string. To avoid regressions, the CL keeps
      >    the HeapConstant type and changes the runtime and builtin code to
      >    always produce the canonical "0" string.
      >
      > A few tests were failing because they check for truncations to work
      > and prevent deoptimization. However, AssertType nodes destroy all
      > truncations (which is by design), so these tests are incompatible
      > and now disabled for the assert_types variant.
      >
      > Drive-by fix: a few minor Torque issues that came up.
      >
      > Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Reviewed-by: Omer Katz <omerkatz@chromium.org>
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#77565}
      
      Change-Id: Ia779a11fc811846194c7a8d1e40b372b265e7ea4
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3247034
      Auto-Submit: Maya Lekova <mslekova@chromium.org>
      Owners-Override: Maya Lekova <mslekova@chromium.org>
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/main@{#77566}
      54f90462
    • Tobias Tebbi's avatar
      [turbofan] extend type asserts to cover all JS types · 45227ffd
      Tobias Tebbi authored
      Extend type assertions to all types covering JavaScript values.
      This is achieved by allocating type representations on the heap using
      newly defined HeapObject subclasses. To allocate these in the compiler,
      we disable concurrent compilation for the --assert-types flag for now.
      
      Fix two type errors that came up with the existing tests:
      1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of
         OtherObject.
      2. OperationTyper::NumberToString(Type) can type the result as the
         HeapConstant Factory::zero_string(). However, NumberToString does
         not always produce this string. To avoid regressions, the CL keeps
         the HeapConstant type and changes the runtime and builtin code to
         always produce the canonical "0" string.
      
      A few tests were failing because they check for truncations to work
      and prevent deoptimization. However, AssertType nodes destroy all
      truncations (which is by design), so these tests are incompatible
      and now disabled for the assert_types variant.
      
      Drive-by fix: a few minor Torque issues that came up.
      
      Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77565}
      45227ffd
  3. 04 Mar, 2019 1 commit
  4. 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