1. 27 Apr, 2021 1 commit
  2. 23 Apr, 2021 1 commit
    • Nico Hartmann's avatar
      [TurboFan] Streamline BigInt.asUintN lowering · 98300313
      Nico Hartmann authored
      This CL applies the following changes:
      - JSCallReducer no longer generates a CheckBigInt in front of the
        generated BigIntAsUintN.
      - This results in a slight change of the semantics of the latter, which
        now includes the necessary type check. Typer and Verifier are changed
        accordingly.
      - The BigIntAsUintN operator is now effectful, since it can now deopt.
      - IrOpcode::kBigIntAsUintN is now lowered in SimplifedLowering instead
        of EffectControlLinearizer, the necessary type check is introduced
        by the RepresentationChanger.
      - Adds a small mjsunit test to check the correct deoptimization behavior
        of optimized BigInt.asUintN.
      ==> Remove UseInfo::TruncatingWord64()!
      
      Drive-by: Fix an issue in ChangeUnaryToPureBinaryOp when the new_input
      is at index 1.
      Drive-by: Introduce an %Is64Bit() intrinsic to allow tests to
      distinguish 32 and 64 bit architectures.
      
      Bug: v8:11682
      Change-Id: I448f892d3bd2280d731ae5b248c833de8faf1bd5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843816
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74147}
      98300313
  3. 08 Jul, 2020 1 commit
  4. 02 Jun, 2020 1 commit
  5. 07 May, 2020 1 commit
  6. 05 May, 2020 1 commit
    • Georg Neis's avatar
      Revert "[turbofan] Refine a DCHECK" · 3ee4ead5
      Georg Neis authored
      This reverts commit a596efcc.
      
      Reason for revert: Was incorrect. Holes can appear in dead code.
      
      Original change's description:
      > [turbofan] Refine a DCHECK
      >
      > Hole checks are done using a lower level comparison.
      >
      > Change-Id: I61c5b787f12564ad3553d395a36938a00f5dd554
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172418
      > Auto-Submit: Georg Neis <neis@chromium.org>
      > Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67466}
      
      TBR=neis@chromium.org,nicohartmann@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Change-Id: I47aff68cf8e224882a3eeac0d9edfe5a6228f0f2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2181324
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67561}
      3ee4ead5
  7. 29 Apr, 2020 1 commit
  8. 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
  9. 20 Apr, 2020 2 commits
  10. 25 Mar, 2020 1 commit
  11. 18 Mar, 2020 2 commits
  12. 12 Mar, 2020 1 commit
  13. 11 Mar, 2020 1 commit
  14. 20 Nov, 2019 1 commit
  15. 19 Nov, 2019 1 commit
  16. 16 Oct, 2019 1 commit
  17. 15 Jul, 2019 1 commit
  18. 12 Jul, 2019 1 commit
  19. 05 Jul, 2019 1 commit
  20. 02 Jul, 2019 1 commit
  21. 26 Jun, 2019 1 commit
  22. 25 Jun, 2019 2 commits
  23. 24 Jun, 2019 1 commit
    • Mathias Bynens's avatar
      [objects] Rename JSValue to JSPrimitiveWrapper · e428dfd7
      Mathias Bynens authored
      We currently use the class name “JSValue” for JSObjects that wrap
      primitive values. This name is a common source of confusion. This patch
      switches to a name that’s more clear.
      
      In addition to manual tweaks, the patch applies the following mechanical
      global replacements:
      
      before                          | after
      --------------------------------|--------------------------------------
      if_valueisnotvalue              | if_valueisnotwrapper
      if_valueisvalue                 | if_valueiswrapper
      js_value                        | js_primitive_wrapper
      JS_VALUE_TYPE                   | JS_PRIMITIVE_WRAPPER_TYPE
      JSPrimitiveWrapperType          | JSPrimitiveWrapper type
      jsvalue                         | js_primitive_wrapper
      JSValue                         | JSPrimitiveWrapper
      _GENERATED_JSVALUE_FIELDS       | _GENERATED_JSPRIMITIVE_WRAPPER_FIELDS
      
      Change-Id: I9d9edea784eab6067b013e1f781e4db2070f807c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1672942Reviewed-by: 's avatarTamer Tas <tmrts@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Mathias Bynens <mathias@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62337}
      e428dfd7
  24. 28 May, 2019 1 commit
  25. 23 May, 2019 1 commit
  26. 22 May, 2019 1 commit
  27. 18 Apr, 2019 2 commits
  28. 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
  29. 02 Jan, 2019 1 commit
  30. 11 Dec, 2018 1 commit
  31. 21 Nov, 2018 1 commit
  32. 19 Nov, 2018 1 commit
    • Georg Neis's avatar
      Revert "[turbofan] Improve NumberMultiply typing rule." · 858fc3f6
      Georg Neis authored
      This reverts commit 585b4eef.
      
      Reason for revert: Speculative, crbug 906567.
      
      Original change's description:
      > [turbofan] Improve NumberMultiply typing rule.
      > 
      > The NumberMultiply typing rule gave up in the presence of NaN inputs,
      > but we can still infer useful ranges here and just union the result
      > of that with the NaN propagation (similar for MinusZero propagation).
      > This way we can still makes sense of these ranges at the uses.
      > 
      > Bug: v8:8015
      > Change-Id: Ic4c5e8edc6c68776ff3baca9628ad7de0f8e2a92
      > Reviewed-on: https://chromium-review.googlesource.com/c/1261143
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#56539}
      
      TBR=sigurds@chromium.org,bmeurer@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:8015
      Change-Id: I3c652bafbbc0e5d1ad4ff288264fd4f4cbf71330
      Reviewed-on: https://chromium-review.googlesource.com/c/1340253Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57602}
      858fc3f6
  33. 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
  34. 15 Oct, 2018 1 commit
  35. 10 Oct, 2018 1 commit
  36. 25 Sep, 2018 1 commit