1. 22 Apr, 2020 1 commit
  2. 19 Nov, 2019 1 commit
  3. 28 May, 2019 1 commit
  4. 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
  5. 24 May, 2019 1 commit
  6. 23 May, 2019 1 commit
  7. 13 Feb, 2019 1 commit
  8. 23 Nov, 2018 1 commit
  9. 23 Aug, 2018 1 commit
  10. 07 Aug, 2018 1 commit
  11. 03 Aug, 2018 1 commit
  12. 09 Jul, 2018 1 commit
    • Sigurd Schneider's avatar
      [turbofan] Use relative calls/jumps on arm for builtins · 23dbb81d
      Sigurd Schneider authored
      This CL uses pc-relative jumps and calls (B/BL) for calls from embedded
      builtins to embedded builtins. To make this work, the code range size is
      limited to 32MB on arm during mksnapshot, which ensures that all builtin
      to builtin offsets for jumps/calls fit into the B/BL immediate. At code
      generation time, we put a placeholder into the instruction offset which
      we resolve to the right code object when the code is copied to the heap.
      We use a new relocation mode RELATIVE_CODE_TARGET for these relative jumps.
      The relocation mode RELATIVE_CODE_TARGET should never appear after
      generating the snapshot.
      
      We modify the target_address/set_target_address methods of RelocInfo
      such that they return the absolute target addresses for pc-relative B/BL
      instructions. This ensures that the GC can treat RELATIVE_CODE_TARGET in
      the same way as code targets. This, however, only matters during
      snapshot creation time, and production code never contains
      RELATIVE_CODE_TARGET relocations.
      
      Bug: v8:6666
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
      Change-Id: If7eab83ad588859ca87c654a5ddc3e37caea884c
      Reviewed-on: https://chromium-review.googlesource.com/1117181Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54320}
      23dbb81d
  13. 26 Jun, 2018 1 commit
    • Sigurd Schneider's avatar
      [turbofan] Support kRootRegisterBias on all platforms · ba39d635
      Sigurd Schneider authored
      We had a kRootRegisterBias on x64 before. This CL ports the feature to
      all other platforms as well. The root register bias is helpful to adjust
      the value of the root register, which allows to better utilize signed
      immediate offset constants in load instructions.
      
      We currently use a separate add instruction to add kRootRegisterBias
      in the code that initializes the root register. This could be improved
      by adding a custom relocation mode ensuring that instead of the root
      address, the root address plus the bias is inserted (and in this way
      the add instruction can be omitted).
      
      Bug: v8:6666
      Change-Id: I55cf02ab85d11e3c6d0d83a8f7905dbf924890f1
      Reviewed-on: https://chromium-review.googlesource.com/1113539
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54023}
      ba39d635
  14. 14 Apr, 2018 1 commit
    • Jakob Kummerow's avatar
      [ubsan] Change Address typedef to uintptr_t · 2459046c
      Jakob Kummerow authored
      The "Address" type is V8's general-purpose type for manipulating memory
      addresses. Per the C++ spec, pointer arithmetic and pointer comparisons
      are undefined behavior except within the same array; since we generally
      don't operate within a C++ array, our general-purpose type shouldn't be
      a pointer type.
      
      Bug: v8:3770
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: Ib96016c24a0f18bcdba916dabd83e3f24a1b5779
      Reviewed-on: https://chromium-review.googlesource.com/988657
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52601}
      2459046c
  15. 21 Feb, 2018 1 commit
  16. 10 Jan, 2018 1 commit
    • Pierre Langlois's avatar
      [arm] Restrict usage of pc-relative LDR. · 5361c57b
      Pierre Langlois authored
      Disallow using the PC as a base in LDR and instead provide a dedicated assembler
      method for pc-relative loads. The reason for this is that the generic
      `Assembler::ldr` method may decide to generate more instructions if the offset
      is out of range, and if the PC was the base, we would get surprising
      results. For example:
      
      ~~~
      ldr r0, [pc, #0xcabba9e]
      ~~~
      
      is not equivalent to:
      
      ~~~
      movw ip, #0xba9e
      movt ip, #0xcab
      ldr r0, [pc, ip]
      ~~~
      
      since the reference to the PC has moved down two instructions!
      
      We could teach the assembler to handle those cases correctly, but pc-relative
      loads are used in specific cases only so that's not necessary.
      
      As a drive-by, remove a reference to code aging.
      
      Bug: 
      Change-Id: I586d83a418db52cf28d3b524f889bf40f077998a
      Reviewed-on: https://chromium-review.googlesource.com/847008Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
      Cr-Commit-Position: refs/heads/master@{#50475}
      5361c57b
  17. 18 Oct, 2017 1 commit
  18. 17 Oct, 2017 1 commit
  19. 16 May, 2017 1 commit
  20. 24 Apr, 2017 1 commit
  21. 18 Jan, 2017 1 commit
  22. 15 Dec, 2016 1 commit
  23. 25 Nov, 2016 1 commit
  24. 25 Aug, 2016 1 commit
  25. 14 Mar, 2016 1 commit
  26. 17 Feb, 2016 1 commit
  27. 30 Sep, 2015 1 commit
  28. 14 Aug, 2015 1 commit
  29. 04 Jun, 2015 1 commit
    • mbrandy's avatar
      Add support for Embedded Constant Pools for PPC and Arm · eac7f046
      mbrandy authored
      Embed constant pools within their corresponding Code
      objects.
      
      This removes support for out-of-line constant pools in favor
      of the new approach -- the main advantage being that it
      eliminates the need to allocate and manage separate constant
      pool array objects.
      
      Currently supported on PPC and ARM.  Enabled by default on
      PPC only.
      
      This yields a 6% improvment in Octane on PPC64.
      
      R=bmeurer@chromium.org, rmcilroy@chromium.org, michael_dawson@ca.ibm.com
      BUG=chromium:478811
      LOG=Y
      
      Review URL: https://codereview.chromium.org/1162993006
      
      Cr-Commit-Position: refs/heads/master@{#28801}
      eac7f046
  30. 03 Jun, 2015 1 commit
  31. 02 Jun, 2015 1 commit
    • mbrandy's avatar
      Add support for Embedded Constant Pools for PPC and Arm · a9404029
      mbrandy authored
      Embed constant pools within their corresponding Code
      objects.
      
      This removes support for out-of-line constant pools in favor
      of the new approach -- the main advantage being that it
      eliminates the need to allocate and manage separate constant
      pool array objects.
      
      Currently supported on PPC and ARM.  Enabled by default on
      PPC only.
      
      This yields a 6% improvment in Octane on PPC64.
      
      R=danno@chromium.org, svenpanne@chromium.org, bmeurer@chromium.org, rmcilroy@chromium.org, dstence@us.ibm.com, michael_dawson@ca.ibm.com
      BUG=chromium:478811
      LOG=Y
      
      Review URL: https://codereview.chromium.org/1131783003
      
      Cr-Commit-Position: refs/heads/master@{#28770}
      a9404029
  32. 06 Feb, 2015 1 commit
  33. 08 Dec, 2014 1 commit
  34. 30 Oct, 2014 1 commit
  35. 21 Aug, 2014 1 commit
  36. 04 Aug, 2014 1 commit
  37. 03 Jul, 2014 1 commit
    • rmcilroy@chromium.org's avatar
      [Arm]: Enable use of extended out-of-line constant pool for Arm. · 40af47d4
      rmcilroy@chromium.org authored
       - Adds support to the Arm assembler to use extended constant pools.
       - Update (set_)target_address_at to support extended constant pool load
         updates.
       - Replace Operand::is_single_instruction with Operand::instructions_required
         Due to the fact that different constant pool load types require different
         numbers of instructions.
       - Various cleanups of ConstantPoolBuilder to cleaner integration of the
         extended constant pool building.
       - Update GetRelocatedValue such that offsets to both map_check and bool_load
         are explicitly provided, rather than location of bool_load being inferred
         based on map_check, since the code inbetween is no longer of a predictable
         size.
       - Update MacroAssembler::GetRelocatedValueLocation() to add support for
         getting a value from an extended constant pool entry.
       - Update Debug::SetAfterBreakTarget() to use target_address_from_return_address
         when checking for debug breaks at constant pool load points.
       - Change ConstantPoolIterateBody to iterate over both heap and code pointer in
         the small section before moving onto the extended section, to work around the
         requirement of the serializer that pointers are iterated in-order.
       - Increase old_pointer_space SizeOfFirstPage() to offset the fact that constant
         pools are now in the old pointer space (rather than code).
      
      R=ulan@chromium.org
      
      Review URL: https://codereview.chromium.org/356393003
      
      git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22209 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      40af47d4
  38. 27 Jun, 2014 1 commit
  39. 25 Jun, 2014 1 commit
  40. 23 Jun, 2014 1 commit