1. 29 Jun, 2020 1 commit
  2. 24 Jun, 2020 3 commits
  3. 23 Jun, 2020 1 commit
  4. 22 Jun, 2020 1 commit
  5. 18 Jun, 2020 2 commits
  6. 16 Jun, 2020 1 commit
  7. 15 Jun, 2020 1 commit
    • Jakob Gruber's avatar
      [scanner] Update outdated DCHECK · 9aa3c608
      Jakob Gruber authored
      We recently changed uc32 to be an unsigned type, and with the invalid
      marker being static_cast<uc32>(-1) this DCHECK no longer holds. After
      this CL it expicitly checks for the invalid marker.
      
      Bug: v8:10568,chromium:1094226
      Change-Id: Idd9efe055b38387e3e37b132cb786cca130767b3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2245592
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68333}
      9aa3c608
  8. 10 Jun, 2020 2 commits
  9. 09 Jun, 2020 2 commits
  10. 04 Jun, 2020 4 commits
  11. 03 Jun, 2020 3 commits
  12. 02 Jun, 2020 2 commits
  13. 28 May, 2020 4 commits
    • Mythri A's avatar
      Hold on to FeedbackMetadata when allocating feedback vectors · 97ae1010
      Mythri A authored
      Allocating a new feedback vector happens in two steps: We create an
      empty structure and then initialize the array based on the
      FeedbackMetadata.When allocating a new feedback array we could trigger
      a GC which might flush the bytecode and associated feedback metadata.
      This shouldn't happen in normal cases, because we either allocate
      feedback vector after compilation or when we reach the expected budget.
      In both cases, the age of the feedback vector should be 0 and hence
      bytecode shouldn't be flushed. However, with debugger enabled we may
      allocate feedback vectors even when the bytecode array is old
      for example: when we enable precise invocation counters. This also
      causes issues in tests with --stress-flush-bytecode. In the stress mode
      we flush bytecode without considering the age. Holding on to the
      feedback metadata prevents crashes in such cases.
      
      Bug: v8:10560
      Change-Id: Ie806ff4102cb5fcf257c8683d5ca957853e38c05
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218066
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Auto-Submit: Mythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68052}
      97ae1010
    • Mythri A's avatar
      [test] Disable stress-bytecode-flush on mjsunit/regress/regress-786784 · 8377a2b3
      Mythri A authored
      Temporarily disable stress-bytecode-flush on
      mjsunit/regress/regress-786784 while we investigate failures related
      to bytecode flushing.
      
      Bug: v8:10560
      Change-Id: Ieb5cc7ba87da04133e98c6be25c9a499d79543e0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218038Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Auto-Submit: Mythri Alle <mythria@chromium.org>
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68046}
      8377a2b3
    • Nico Hartmann's avatar
      Fix feedback loss when builtins throw · fd5cc883
      Nico Hartmann authored
      In BinaryOpAssembler::Generate_BinaryOperationWithFeedback, the
      feedback is stored only after the respective builtin/runtime call.
      If this call throws an exception, the feedback is lost, leading
      to a deopt loop in some cases. This CL fixes that issue by writing
      the gathered feedback before passing control to the builtin.
      
      Bug: chromium:1077197, v8:9441
      Change-Id: I20e4b14815520224e2c6f8af1af6a89f754ccddf
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2202904
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68038}
      fd5cc883
    • 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
  14. 26 May, 2020 1 commit
  15. 25 May, 2020 1 commit
    • Ross McIlroy's avatar
      [TurboProp] Don't try to rewire unreachable blocks to end. · f34771f7
      Ross McIlroy authored
      We can't consistently rewire the successor blocks of an unreachable node to
      disconnect them from the graph when we are trying to maintain the schedule.
      Instead simply leave the code there. As a future optimization we could add a
      proper scheduled dead code elimination phase which can deal with this.
      
      As a side-effect, one of the tests sees a int64 DeadValue, so add support for that
      in the instruction selector.
      
      BUG=chromium:1083272,chromium:1083763,chromium:1084953,v8:9684
      
      Change-Id: I69a6feaeef4eae62110392e27ea848b28bccf787
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209061
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67953}
      f34771f7
  16. 21 May, 2020 1 commit
  17. 20 May, 2020 1 commit
  18. 19 May, 2020 3 commits
  19. 14 May, 2020 1 commit
  20. 13 May, 2020 2 commits
  21. 12 May, 2020 1 commit
  22. 11 May, 2020 2 commits