1. 04 Dec, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] uniform flattening and string access in Torque · 65d2c4b4
      Tobias Tebbi authored
      Port String::Flatten to Torque (using a fast C call for the
      non-allocating part) and provide fast and easy access to sequential
      string data in Torque: GetStringData() flattens if necessary and
      computes slices that allow direct access.
      
      Applications: String.prototype.replaceAll, String.prototype.endsWith,
        and String.prototype.beginsWith now use GetStringData() and direct
        slice access instead of the slow StringCharCodeAt and they no
        longer bail out to the runtime for flattening.
      
      Drive-by changes:
        - Expose String instance type bits as bitfields and enums in Torque.
        - Fix method lookup in Torque to include superclass methods.
        - Use char8 and char16 types in more places.
        - Allow fast C calls with void return type.
        - Add Torque macros to create subslices.
        - Add no-GC scopes to runtime functions loading external string data.
      
      
      Bug: v8:7793
      Change-Id: I763b9b24212770307c9b2fe9f070f21f65d68d58
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565515
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71611}
      65d2c4b4
  2. 19 Nov, 2020 1 commit
  3. 13 Nov, 2020 1 commit
  4. 12 Nov, 2020 1 commit
  5. 11 Nov, 2020 5 commits
  6. 09 Nov, 2020 1 commit
  7. 28 Oct, 2020 1 commit
  8. 05 Oct, 2020 1 commit
  9. 01 Oct, 2020 1 commit
    • Dan Elphick's avatar
      [CSA] Tnodify CodeAssembler::Parameter · 74a9b9c4
      Dan Elphick authored
      CodeAssembler::Parameter now takes a Type template parameter and
      performs a checked cast to it. There is also UncheckedParameter which
      returns a TNode but doesn't check the cast. The original Parameter
      method is still there as UntypedParameter.
      
      Parameter<T>(x) in many cases replaces CAST(Parameter(x)), where the
      cast is performed inside Parameter. Since Parameter is not a macro,
      this means it cannot see the original expression or its file name and
      line number. So the error messages are vaguely useful, Parameter<T>()
      takes a SourceLocation parameter which with a default value of
      SourceLocation::Current(), which at least gives us the file name and
      line number for the error message.
      
      Bug: v8:6949, v8:10933
      Change-Id: I27157bec7dc7462210c1eb9c430c0180217d25c1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2435106Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70264}
      74a9b9c4
  10. 02 Sep, 2020 1 commit
  11. 05 Aug, 2020 1 commit
    • Jakob Gruber's avatar
      [nci] Replace CompilationTarget with a new Code::Kind value · c51041f4
      Jakob Gruber authored
      With the new Turbofan variants (NCI and Turboprop), we need a way to
      distinguish between them both during and after compilation. We
      initially introduced CompilationTarget to track the variant during
      compilation, but decided to reuse the code kind as the canonical spot to
      store this information instead.
      
      Why? Because it is an established mechanism, already available in most
      of the necessary spots (inside the pipeline, on Code objects, in
      profiling traces).
      
      This CL removes CompilationTarget and adds a new
      NATIVE_CONTEXT_INDEPENDENT kind, plus helper functions to determine
      various things about a given code kind (e.g.: does this code kind
      deopt?).
      
      As a (very large) drive-by, refactor both Code::Kind and
      AbstractCode::Kind into a new CodeKind enum class.
      
      Bug: v8:8888
      Change-Id: Ie858b9a53311b0731630be35cf5cd108dee95b39
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336793
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69244}
      c51041f4
  12. 27 Jul, 2020 1 commit
  13. 24 Jul, 2020 1 commit
  14. 22 Jul, 2020 2 commits
    • Seth Brenith's avatar
      Profile-guided optimization of builtins · 922983df
      Seth Brenith authored
      Design doc:
      https://docs.google.com/document/d/1szInbXZfaErWW70d30hJsOLL0Es-l5_g8d2rXm1ZBqI/edit?usp=sharing
      
      V8 can already collect data about how many times each basic block in the
      builtins is run. This change enables using that data for profile-guided
      optimization. New comments in BUILD.gn describe how to use this feature.
      
      A few implementation details worth mentioning, which aren't covered in
      the design doc:
      
      - BasicBlockProfilerData currently contains an array of RPO numbers.
        However, this array is always just [0, 1, 2, 3, ...], so this change
        removes that array. A new DCHECK in BasicBlockInstrumentor::Instrument
        ensures that the removal is valid.
      
      - RPO numbers, while useful for printing data that matches with the
        stringified schedule, are not useful for matching profiling data with
        blocks that haven't been scheduled yet. This change adds a new array
        of block IDs in BasicBlockProfilerData, so that block counters can be
        used for PGO.
      
      - Basic block counters need to be written to a file so that they can be
        provided to a subsequent run of mksnapshot, but the design doc doesn't
        specify the transfer format or what file is used. In this change, I
        propose using the existing v8.log file for that purpose. Block count
        records look like this:
      
        block,TestLessThanHandler,37,29405
      
        This line indicates that block ID 37 in TestLessThanHandler was run
        29405 times. If multiple lines refer to the same block, the reader
        adds them all together. I like this format because it's easy to use:
        - V8 already has robust logic for creating the log file, naming it to
          avoid conflicts in multi-process situations, etc.
        - Line order doesn't matter, and interleaved writes from various
          logging sources are fine, given that V8 writes each line atomically.
        - Combining multiple sources of profiling data is as simple as
          concatenating their v8.log files together.
      
      - It is a good idea to avoid making any changes based on profiling data
        if the function being compiled doesn't match the one that was
        profiled, since it is common to use profiling data downloaded from a
        central lab which is updated only periodically. To check whether a
        function matches, I propose using a hash of the Graph state right
        before scheduling. This might be stricter than necessary, as some
        changes to the function might be small enough that the profile data is
        still relevant, but I'd rather err on the side of not making incorrect
        changes. This hash is also written to the v8.log file, in a line that
        looks like this:
      
        builtin_hash,LdaZeroHandler,3387822046
      
      Bug: v8:10470
      Change-Id: I429e5ce5efa94e01e7489deb3996012cf860cf13
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2220765
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69008}
      922983df
    • Richard Stotz's avatar
      [turbofan][wasm][arm64] Improved saturated conversions float32 to int32. · fafb4769
      Richard Stotz authored
      The design of this change was discussed here:
      https://docs.google.com/document/d/12otOj6SyXMXj0Dnnx9B6MGLMRwHPhg6RIZRazVw3tFA/
      
      Bug: v8:10720
      Change-Id: I8292dcf7272bdf4526a2d630b49fc374cdb01bdc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2304570
      Commit-Queue: Richard Stotz <rstz@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68994}
      fafb4769
  15. 10 Jul, 2020 1 commit
  16. 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
  17. 26 May, 2020 1 commit
  18. 08 May, 2020 1 commit
    • Nico Hartmann's avatar
      Revert "[turbofan] Improve equality on NumberOrOddball" · f4b98cc6
      Nico Hartmann authored
      This reverts commit 6204768b.
      
      Reason for revert: A number of Clusterfuzz reports (e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=1079474)
      
      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=rmcilroy@chromium.org,neis@chromium.org,mythria@chromium.org,nicohartmann@chromium.org
      
      Change-Id: I3410310ed2b1ff2eaee70c1b91c3151d35866108
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:5660
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2190414Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67673}
      f4b98cc6
  19. 07 May, 2020 1 commit
    • Nico Hartmann's avatar
      [turbofan] Improve equality on NumberOrOddball · 6204768b
      Nico Hartmann authored
      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/+/2162854Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67645}
      6204768b
  20. 23 Apr, 2020 1 commit
  21. 21 Apr, 2020 1 commit
  22. 10 Mar, 2020 1 commit
  23. 25 Feb, 2020 1 commit
  24. 18 Feb, 2020 1 commit
  25. 17 Feb, 2020 2 commits
  26. 14 Feb, 2020 1 commit
  27. 07 Feb, 2020 2 commits
  28. 10 Jan, 2020 1 commit
  29. 20 Dec, 2019 1 commit
  30. 17 Dec, 2019 2 commits
  31. 11 Dec, 2019 1 commit
  32. 28 Nov, 2019 1 commit