1. 17 Mar, 2021 1 commit
  2. 09 Mar, 2021 1 commit
  3. 25 Feb, 2021 1 commit
  4. 24 Feb, 2021 1 commit
  5. 22 Feb, 2021 1 commit
  6. 02 Feb, 2021 1 commit
  7. 27 Jan, 2021 1 commit
  8. 21 Jan, 2021 1 commit
  9. 18 Jan, 2021 1 commit
  10. 12 Jan, 2021 1 commit
  11. 04 Jan, 2021 1 commit
  12. 24 Dec, 2020 1 commit
  13. 19 Dec, 2020 1 commit
  14. 17 Dec, 2020 1 commit
  15. 14 Dec, 2020 1 commit
  16. 02 Dec, 2020 1 commit
  17. 24 Nov, 2020 1 commit
  18. 09 Nov, 2020 1 commit
  19. 05 Nov, 2020 1 commit
  20. 04 Nov, 2020 1 commit
  21. 28 Oct, 2020 1 commit
  22. 26 Oct, 2020 1 commit
  23. 19 Oct, 2020 1 commit
  24. 15 Oct, 2020 1 commit
  25. 13 Oct, 2020 1 commit
  26. 18 Sep, 2020 1 commit
  27. 16 Sep, 2020 1 commit
  28. 10 Sep, 2020 1 commit
  29. 08 Sep, 2020 1 commit
  30. 30 Jun, 2020 1 commit
  31. 13 May, 2020 1 commit
  32. 05 May, 2020 1 commit
  33. 21 Apr, 2020 1 commit
  34. 19 Mar, 2020 1 commit
  35. 17 Mar, 2020 1 commit
  36. 10 Feb, 2020 1 commit
  37. 10 Jan, 2020 2 commits
    • 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
    • Zhao Jiazhong's avatar
      [mips] Allow concurrent patching of the jump table. · cb631803
      Zhao Jiazhong authored
      Bug: v8:8974
      Change-Id: Ib1e1c84b79190359d5ad519509b881e93d519604
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1989323
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Auto-Submit: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65697}
      cb631803
  38. 22 Nov, 2019 1 commit
  39. 08 Nov, 2019 1 commit