1. 24 Jun, 2020 1 commit
  2. 12 Jun, 2020 1 commit
  3. 10 Jun, 2020 1 commit
    • Georg Neis's avatar
      [runtime] Fix reentrancy bug in JSFunction::EnsureHasInitialMap · 0817d7ee
      Georg Neis authored
      Foozie came up with a mind-boggling example hitting a similarly
      mind-boggling bug: object construction (JSObject::New) wants to create
      the constructor's function initial map (JSFunction::GetDerivedMap ->
      JSFunction::EnsureHasInitialMap). To do so, it calls
      JSFunction::CalculateExpectedNofProperties. This harmless sounding
      function triggers compilation of the function. Since we're running with
      --always-opt, this is an optimizing compilation. Turbofan ends up
      depending on the function's "prototype" property, for which it wants to
      create the initial map so that it can install the code dependency. That
      is, EnsureHasInitialMap is reentered. At this point there is no further
      compilation attempt because the bytecode now exists. The initial map is
      created and installed on the function, and TF records the code
      dependency on that map. When CalculateExpectedNofProperties returns
      control to the outer EnsureHasInitialMap, yet another initial map is
      created and set on the function, forgetting the previous one and thus
      the code dependency.
      
      I'm not sure if this bug can only be observed with --always-opt. The fix
      is general.
      
      Bug: chromium:1092011
      Change-Id: I8b972748e49b9eb8f06fa17ea9ca037de2bd7532
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2238570Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68292}
      0817d7ee
  4. 09 Jun, 2020 1 commit
  5. 08 Jun, 2020 1 commit
  6. 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
  7. 15 May, 2020 1 commit
  8. 07 May, 2020 1 commit
  9. 28 Apr, 2020 1 commit
  10. 27 Apr, 2020 1 commit
  11. 22 Apr, 2020 1 commit
  12. 21 Apr, 2020 1 commit
    • Georg Neis's avatar
      Reland "[turbofan] Fix bug in Number.Min/Max typings" · 898b8915
      Georg Neis authored
      This reverts commit f442b03f.
      
      Reason for reland: Wrongly reverted.
      
      Original change's description:
      > Revert "[turbofan] Fix bug in Number.Min/Max typings"
      > 
      > This reverts commit 4158af83.
      > 
      > Reason for revert: causing UBSAN failures:
      > 
      > https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/10729?
      > 
      > 
      > Original change's description:
      > > [turbofan] Fix bug in Number.Min/Max typings
      > > 
      > > They try to be very precise about when the result can be -0,
      > > but do so incorrectly. I'm changing the code to just do the
      > > simple thing instead. Let's see how that affects performance.
      > > 
      > > Bug: chromium:1072171
      > > Change-Id: I9737a84aa19d06685af5b7bca541e348dc37cca8
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157028
      > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > > Commit-Queue: Georg Neis <neis@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#67246}
      > 
      > TBR=neis@chromium.org,tebbi@chromium.org
      > 
      > Change-Id: I0d9b312e27f5a8bbbebeccdc9819fa94f10af139
      > No-Presubmit: true
      > No-Tree-Checks: true
      > No-Try: true
      > Bug: chromium:1072171
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157646
      > Reviewed-by: Francis McCabe <fgm@chromium.org>
      > Commit-Queue: Francis McCabe <fgm@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67249}
      
      TBR=neis@chromium.org,tebbi@chromium.org,fgm@chromium.org
      
      Change-Id: Ida36ca584a5af5da887189328c8da195b26285d4
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:1072171
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157368Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67263}
      898b8915
  13. 20 Apr, 2020 2 commits
  14. 15 Apr, 2020 1 commit
    • Leszek Swirski's avatar
      [turbofan] Avoid megamorphic loads for zero-map mono/polymorphic sites · 8428feed
      Leszek Swirski authored
      Soft-deopt for mono/polymorphic property accesses that don't have any
      maps, and only allow zero-map feedback to be monomorphic. This makes
      sure we only emit a megamorphic LoadIC builtin call if the IC was
      actually megamorphic.
      
      JSGenericLowering assumed that zero maps meant that a load site is
      megamorphic. However, it can be the case that the call-site is
      monomorphic or polymorphic, and the maps had died. In this case we don't
      want to call the megamorphic IC builtin, as on a stub cache miss we
      fallback to a normal LoadIC miss, which can record mono/polymorphic
      feedback in the IC. After this, we'll enter a miss loop in the
      megamorphic load builtin, and worse the LoadIC assumes that there's
      something "wrong" with the feedback, so it'll keep trying to reconfigure
      the handler (possibly allocating new load handlers if this is a
      prototype field access).
      
      As a drive-by, rewrite GetRelevantReceiverMaps to be an in-place
      filtering of the maps rather than copying them.
      
      Change-Id: I0c25bfa606367fa81c43223bbd56cdadb5e789ef
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2150586Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67152}
      8428feed
  15. 14 Apr, 2020 1 commit
  16. 08 Apr, 2020 1 commit
  17. 06 Apr, 2020 1 commit
  18. 01 Apr, 2020 1 commit
  19. 25 Mar, 2020 1 commit
  20. 20 Mar, 2020 1 commit
  21. 17 Mar, 2020 1 commit
  22. 29 Feb, 2020 1 commit
  23. 19 Feb, 2020 2 commits
  24. 18 Feb, 2020 1 commit
  25. 13 Feb, 2020 1 commit
  26. 20 Jan, 2020 1 commit
    • Georg Neis's avatar
      [turbofan] Don't verify context input of Create*Context nodes · e33d6338
      Georg Neis authored
      The verifier tried to assert that the context input of Create*Context
      nodes has type OtherInternal (all Context constants have that type).
      This didn't quite work because of OSR values so actually it checked
      something much weaker. And what it checked still doesn't work because
      of dead code, in which the context input might statically be known to
      be the undefined value. I'm removing the assertion entirely now.
      
      I suspect that there are other assertions in the verifier that don't
      hold in the OSR code or in dead code. We are discussing a more general
      solution such as inserting TypeGuards in the relevant cases.
      
      Bug: chromium:1037771
      Change-Id: I6fb59c60e7120d5984ea0fe140269f2df6de8708
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2010792
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Auto-Submit: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65871}
      e33d6338
  27. 17 Dec, 2019 4 commits
  28. 05 Dec, 2019 1 commit
  29. 02 Dec, 2019 3 commits
  30. 29 Nov, 2019 1 commit
  31. 28 Nov, 2019 1 commit
  32. 27 Nov, 2019 1 commit
  33. 26 Nov, 2019 1 commit