1. 29 Jul, 2020 2 commits
  2. 28 Jul, 2020 2 commits
  3. 27 Jul, 2020 1 commit
  4. 24 Jul, 2020 1 commit
  5. 22 Jul, 2020 5 commits
    • Ross McIlroy's avatar
      [TurboProp] Add initial DefineOutput phase for fast register allocator · c092c081
      Ross McIlroy authored
      Adds the first phase of the fast register allocator, which runs through
      
      the instruction stream and defines a VirtualRegisterData for each
      virtual register based on how that virtual register is produced. Also
      adds logic to pipeline.cc to allocate and use FastRegistorAllocatorData
      for use throughout the fast register allocation phases.
      
      BUG=v8:9684
      
      Change-Id: I2f4533467346d5f3fdf50a0a1fedd7e4082f0187
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2295364
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69010}
      c092c081
    • 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
    • Frank Tang's avatar
      [Intl] Remove flag for fractionalSecondDigits · 6f356f79
      Frank Tang authored
      DateTimeFormat's fractionalSecondDigits shipped in M84, so we
      can drop the --harmony_intl_dateformat_fractional_second_digits
      flag now.
      
      Bug: v8:10485
      Change-Id: If7a1a8599722073d7382635219a6fb46cdc47474
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2311410Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Frank Tang <ftang@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69007}
      6f356f79
    • Maya Lekova's avatar
      Revert "Reland "[flags] warn about contradictory flags"" · a269ce20
      Maya Lekova authored
      This reverts commit d8f8a7e2.
      
      Reason for revert: Breaks code_serializer variant - https://cr-buildbucket.appspot.com/build/8874070652992164976
      
      Original change's description:
      > Reland "[flags] warn about contradictory flags"
      > 
      > This is a reland of b8f91666
      > Difference to previous CL: Additional functionality to specify
      > incompatible flags based on GN variables and extra-flags, used
      > to fix the issues that came up on the waterfall.
      > 
      > This also changes the rules regarding repeated flags: While
      > explicitly repeated flags are allowed for boolean values as long
      > as they are identical, repeated flags or explicit flags in the
      > presence of an active implication are disallowed for non-boolean
      > flags. The latter simplifies specifying conflict rules in
      > variants.py. Otherwise a rule like
      > 
      > INCOMPATIBLE_FLAGS_PER_EXTRA_FLAG = {
      >   "--gc-interval=*": ["--gc-interval=*"],
      > }
      > 
      > wouldn't work because specifying the same GC interval twice
      > wouldn't actually count as a conflict. This was an issue with
      > test/mjsunit/wasm/gc-buffer.js, which specifies
      > --gc-interval=500 exactly like the extra flag by the stress bot.
      > 
      > Also, this now expands contradictory flags checking to d8 flags
      > for consistency.
      > 
      > Original change's description:
      > > [flags] warn about contradictory flags
      > >
      > > Design Doc: https://docs.google.com/document/d/1lkvu8crkK7Ei39qjkPCFijpNyxWXsOktG9GB-7K34jM/
      > >
      > > Bug: v8:10577
      > > Change-Id: Ib9cfdffa401c48c895bf31caed5ee03545beddab
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154792
      > > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
      > > Reviewed-by: Georg Neis <neis@chromium.org>
      > > Reviewed-by: Tamer Tas <tmrts@chromium.org>
      > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#68168}
      > 
      > Bug: v8:10577
      > Change-Id: I268e590ee18a535b13dee14eeb15ddd0a9ee8341
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235115
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Tamer Tas <tmrts@chromium.org>
      > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#68989}
      
      TBR=machenbach@chromium.org,neis@chromium.org,clemensb@chromium.org,tebbi@chromium.org,tmrts@chromium.org
      
      Change-Id: I7969065b0edbc463a94e530485bc2ab623d77b62
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10577
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2312782Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68992}
      a269ce20
    • Tobias Tebbi's avatar
      Reland "[flags] warn about contradictory flags" · d8f8a7e2
      Tobias Tebbi authored
      This is a reland of b8f91666
      Difference to previous CL: Additional functionality to specify
      incompatible flags based on GN variables and extra-flags, used
      to fix the issues that came up on the waterfall.
      
      This also changes the rules regarding repeated flags: While
      explicitly repeated flags are allowed for boolean values as long
      as they are identical, repeated flags or explicit flags in the
      presence of an active implication are disallowed for non-boolean
      flags. The latter simplifies specifying conflict rules in
      variants.py. Otherwise a rule like
      
      INCOMPATIBLE_FLAGS_PER_EXTRA_FLAG = {
        "--gc-interval=*": ["--gc-interval=*"],
      }
      
      wouldn't work because specifying the same GC interval twice
      wouldn't actually count as a conflict. This was an issue with
      test/mjsunit/wasm/gc-buffer.js, which specifies
      --gc-interval=500 exactly like the extra flag by the stress bot.
      
      Also, this now expands contradictory flags checking to d8 flags
      for consistency.
      
      Original change's description:
      > [flags] warn about contradictory flags
      >
      > Design Doc: https://docs.google.com/document/d/1lkvu8crkK7Ei39qjkPCFijpNyxWXsOktG9GB-7K34jM/
      >
      > Bug: v8:10577
      > Change-Id: Ib9cfdffa401c48c895bf31caed5ee03545beddab
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154792
      > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Tamer Tas <tmrts@chromium.org>
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#68168}
      
      Bug: v8:10577
      Change-Id: I268e590ee18a535b13dee14eeb15ddd0a9ee8341
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235115
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarTamer Tas <tmrts@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68989}
      d8f8a7e2
  6. 21 Jul, 2020 4 commits
  7. 20 Jul, 2020 2 commits
  8. 16 Jul, 2020 1 commit
  9. 14 Jul, 2020 4 commits
  10. 08 Jul, 2020 1 commit
  11. 07 Jul, 2020 1 commit
    • Jakob Gruber's avatar
      [compiler] Enable feedback collection in generic lowering · e63bae12
      Jakob Gruber authored
      Turbofan now has support for generating generic code in two variants,
      with and without feedback collection. Currently, feedback is collected
      only for some load and store operators (historical reasons).
      
      This CL enables feedback collection for (almost) all operators by
      default. The exception in the default TF configuration are call and
      construct variants (see also https://crrev.com/c/2276042). In NCI mode,
      all operators collect feedback.
      
      Regression have looked acceptable in our benchmarks so far. This is an
      experiment to see impact on real world. If successful, the
      non-collecting variants can be removed.
      
      Bug: v8:8888
      Change-Id: I0dddc7113ce94071552d5c4d992471db5ac5f989
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2239571
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68710}
      e63bae12
  12. 03 Jul, 2020 1 commit
  13. 02 Jul, 2020 1 commit
  14. 30 Jun, 2020 1 commit
  15. 25 Jun, 2020 2 commits
  16. 24 Jun, 2020 1 commit
  17. 23 Jun, 2020 2 commits
  18. 22 Jun, 2020 3 commits
  19. 19 Jun, 2020 1 commit
  20. 18 Jun, 2020 2 commits
  21. 12 Jun, 2020 1 commit
  22. 10 Jun, 2020 1 commit