1. 17 Feb, 2020 1 commit
  2. 07 Feb, 2020 1 commit
  3. 06 Feb, 2020 1 commit
  4. 10 Jan, 2020 1 commit
    • Seth Brenith's avatar
      [torque] move more bitfield definitions to Torque · 87c16da5
      Seth Brenith authored
      This change moves the definitions of the bitfield flags used by Symbol
      and Map to Torque. Symbol could directly follow the pattern established
      by SharedFunctionInfo, but Map required some other changes:
      - Until now, Torque bitfield definitions have required unsigned types. I
        thought that this would be the least-surprising behavior, since we
        never sign-extend when decoding bitfield values. However, I believe
        that the amount of churn involved in making ElementsKind be unsigned
        outweighs the benefit we were getting from this restriction (and
        similar difficulties are likely to arise in converting other bitfield
        structs to Torque), so this CL updates Torque to allow signed bitfield
        values.
      - If we try to make Map extend from all of the generated classes that
        define its flags, we end up with class sizing problems because some
        compilers only apply empty base class optimization to the first in a
        row of empty base classes. We could work around this issue by
        generating macros instead of classes, but I took this as an
        opportunity for a minor clean-up instead: rather than having bitfield
        definitions for several different bitfield structs all jumbled
        together in Map, they can be split up. I think this makes the code a
        little easier to follow, but if others disagree I'm happy to implement
        macro generation instead.
      
      Change-Id: Ibf339b0be97f72d740bf1daa8300b471912faeba
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1988934Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#65701}
      87c16da5
  5. 09 Jan, 2020 1 commit
  6. 07 Jan, 2020 1 commit
  7. 19 Nov, 2019 1 commit
  8. 15 Nov, 2019 1 commit
  9. 14 Nov, 2019 1 commit
  10. 05 Nov, 2019 1 commit
  11. 04 Nov, 2019 1 commit
  12. 25 Oct, 2019 1 commit
  13. 22 Oct, 2019 1 commit
  14. 11 Oct, 2019 1 commit
  15. 28 Sep, 2019 1 commit
  16. 19 Aug, 2019 1 commit
  17. 25 Jul, 2019 1 commit
  18. 11 Jul, 2019 1 commit
  19. 20 Jun, 2019 1 commit
    • Yu Yin's avatar
      [mips][lite] Allocate feedback vectors lazily · 82622c52
      Yu Yin authored
      Port: 7629afdb https://crrev.com/c/1520719
      
      Original Commit Message:
      
          Allocate feedback vectors lazily when the function's interrupt budget has
          reached a specified threshold. This cl introduces a new field in the
          ClosureFeedbackCellArray to track the interrupt budget for allocating
          feedback vectors. Using the interrupt budget on the bytecode array could
          cause problems when there are closures across native contexts and we may
          delay allocating feedback vectors in one of them causing unexpected
          performance cliffs. In the long term we may want to remove interrupt budget
          from bytecode array and use context specific budget for tiering up decisions
          as well.
      
      Change-Id: Icddceec22df3dad7861a30f0190397db130db10d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1669116Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Commit-Queue: Yu Yin <xwafish@gmail.com>
      Cr-Commit-Position: refs/heads/master@{#62301}
      82622c52
  20. 18 Jun, 2019 1 commit
  21. 17 Jun, 2019 1 commit
  22. 14 Jun, 2019 1 commit
    • Yu Yin's avatar
      [mips][counters] Introduce proper bottleneck for FunctionCallback. · dadb59eb
      Yu Yin authored
      Port ea420655 https://crrev.com/c/1651470
      
      Original Commit Message:
      
          API calls made via the CallApiCallback builtin, which is used from the
          ICs and optimized code, are currently misattributed to the wrong counter
          InvokeFunctionCallback instead of FunctionCallback. In addition we don't
          use the C trampoline when only runtime call stats are enabled, but the
          Chrome DevTools profiler is not active, which means that these calls
          will not be attrituted properly at all, and that had to be worked around
          using all kinds of tricks (i.e. disabling fast-paths in ICs when RCS is
          active and not inlining calls/property accesses into optimized code
          depending on the state of RCS).
      
          All of this was really brittle and only due to the fact that the central
          builtin didn't properly check for RCS (in addition to checking for the
          CDT profiler). With this fix it's now handled in a central place and
          attributed to the correct category, so user code doesn't need to worry
          about RCS anymore and can just call straight into the fast-path.
      
          core hand-written native code with the API callback logic.
      
      Change-Id: I6bcc8c4d7f4642381803a8b6c8282ceb8f3d056c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1659988
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62163}
      dadb59eb
  23. 11 Jun, 2019 1 commit
  24. 28 May, 2019 1 commit
  25. 27 May, 2019 1 commit
    • Clemens Hammacher's avatar
      [cleanup] Replace simple typedefs by using · a335f2ae
      Clemens Hammacher authored
      This replaces all typedefs that define types and not functions by the
      equivalent "using" declaration.
      
      This was done mostly automatically using this command:
      ag -l '\btypedef\b' src test | xargs -L1 \
           perl -i -p0e 's/typedef ([^*;{}]+) (\w+);/using \2 = \1;/sg'
      
      Patchset 2 then adds some manual changes for typedefs for pointer types,
      where the regular expression did not match.
      
      R=mstarzinger@chromium.org
      TBR=yangguo@chromium.org, jarin@chromium.org
      
      Bug: v8:9183
      Change-Id: I6f6ee28d1793b7ac34a58f980b94babc21874b78
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631409
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61849}
      a335f2ae
  26. 23 May, 2019 2 commits
  27. 22 May, 2019 2 commits
  28. 21 May, 2019 1 commit
  29. 20 May, 2019 5 commits
  30. 17 May, 2019 3 commits
  31. 16 May, 2019 2 commits