1. 02 Jul, 2020 1 commit
  2. 16 Jun, 2020 1 commit
  3. 21 Apr, 2020 1 commit
  4. 17 Mar, 2020 1 commit
  5. 25 Feb, 2020 1 commit
  6. 13 Feb, 2020 1 commit
    • Georgia Kouveli's avatar
      Reland "[arm64] Protect return addresses stored on stack" · 73f88b5f
      Georgia Kouveli authored
      This is a reland of 137bfe47
      
      Original change's description:
      > [arm64] Protect return addresses stored on stack
      > 
      > This change uses the Arm v8.3 pointer authentication instructions in
      > order to protect return addresses stored on the stack.  The generated
      > code signs the return address before storing on the stack and
      > authenticates it after loading it. This also changes the stack frame
      > iterator in order to authenticate stored return addresses and re-sign
      > them when needed, as well as the deoptimizer in order to sign saved
      > return addresses when creating new frames. This offers a level of
      > protection against ROP attacks.
      > 
      > This functionality is enabled with the v8_control_flow_integrity flag
      > that this CL introduces.
      > 
      > The code size effect of this change is small for Octane (up to 2% in
      > some cases but mostly much lower) and negligible for larger benchmarks,
      > however code size measurements are rather noisy. The performance impact
      > on current cores (where the instructions are NOPs) is single digit,
      > around 1-2% for ARES-6 and Octane, and tends to be smaller for big
      > cores than for little cores.
      > 
      > Bug: v8:10026
      > Change-Id: I0081f3938c56e2f24d8227e4640032749f4f8368
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1373782
      > Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66239}
      
      Bug: v8:10026
      Change-Id: Id1adfa2e6c713f6977d69aa467986e48fe67b3c2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051958Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
      Cr-Commit-Position: refs/heads/master@{#66254}
      73f88b5f
  7. 12 Feb, 2020 2 commits
    • Nico Hartmann's avatar
      Revert "[arm64] Protect return addresses stored on stack" · 6a9a67d9
      Nico Hartmann authored
      This reverts commit 137bfe47.
      
      Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Arm%20-%20debug/13072
      
      Original change's description:
      > [arm64] Protect return addresses stored on stack
      > 
      > This change uses the Arm v8.3 pointer authentication instructions in
      > order to protect return addresses stored on the stack.  The generated
      > code signs the return address before storing on the stack and
      > authenticates it after loading it. This also changes the stack frame
      > iterator in order to authenticate stored return addresses and re-sign
      > them when needed, as well as the deoptimizer in order to sign saved
      > return addresses when creating new frames. This offers a level of
      > protection against ROP attacks.
      > 
      > This functionality is enabled with the v8_control_flow_integrity flag
      > that this CL introduces.
      > 
      > The code size effect of this change is small for Octane (up to 2% in
      > some cases but mostly much lower) and negligible for larger benchmarks,
      > however code size measurements are rather noisy. The performance impact
      > on current cores (where the instructions are NOPs) is single digit,
      > around 1-2% for ARES-6 and Octane, and tends to be smaller for big
      > cores than for little cores.
      > 
      > Bug: v8:10026
      > Change-Id: I0081f3938c56e2f24d8227e4640032749f4f8368
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1373782
      > Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66239}
      
      TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,neis@chromium.org,georgia.kouveli@arm.com
      
      Change-Id: I57d5928949b0d403774550b9bf7dc0b08ce4e703
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10026
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051952Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66242}
      6a9a67d9
    • Georgia Kouveli's avatar
      [arm64] Protect return addresses stored on stack · 137bfe47
      Georgia Kouveli authored
      This change uses the Arm v8.3 pointer authentication instructions in
      order to protect return addresses stored on the stack.  The generated
      code signs the return address before storing on the stack and
      authenticates it after loading it. This also changes the stack frame
      iterator in order to authenticate stored return addresses and re-sign
      them when needed, as well as the deoptimizer in order to sign saved
      return addresses when creating new frames. This offers a level of
      protection against ROP attacks.
      
      This functionality is enabled with the v8_control_flow_integrity flag
      that this CL introduces.
      
      The code size effect of this change is small for Octane (up to 2% in
      some cases but mostly much lower) and negligible for larger benchmarks,
      however code size measurements are rather noisy. The performance impact
      on current cores (where the instructions are NOPs) is single digit,
      around 1-2% for ARES-6 and Octane, and tends to be smaller for big
      cores than for little cores.
      
      Bug: v8:10026
      Change-Id: I0081f3938c56e2f24d8227e4640032749f4f8368
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1373782
      Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66239}
      137bfe47
  8. 03 Feb, 2020 1 commit
  9. 16 Jan, 2020 1 commit
  10. 14 Nov, 2019 1 commit
  11. 28 Oct, 2019 1 commit
  12. 04 Oct, 2019 1 commit
  13. 03 Oct, 2019 1 commit
  14. 30 Sep, 2019 1 commit
  15. 26 Sep, 2019 1 commit
  16. 17 Sep, 2019 1 commit
  17. 28 May, 2019 1 commit
  18. 27 May, 2019 1 commit
  19. 24 May, 2019 1 commit
  20. 21 May, 2019 1 commit
  21. 02 May, 2019 1 commit
  22. 11 Mar, 2019 1 commit
  23. 05 Nov, 2018 1 commit
  24. 25 Oct, 2018 1 commit
  25. 14 Aug, 2018 3 commits
    • Georgia Kouveli's avatar
      [arm64] Clean up of move operations. · de3f3cf0
      Georgia Kouveli authored
      * Perform the lookups into the builtins constant table and external reference
        table in the generic version of Mov that accepts an Operand source. This
        makes sure we do not miss looking up constants and external references when
        the generic Mov is called.
      * Remove Mov(ExternalReference) as ExternalReference can be implicitly converted
        to an Operand.
      * Remove two Move functions that are unused in architecture-independent code.
        Replace their uses in arm64-specific code with the generic Mov, which does all
        the necessary work now.
      
      Change-Id: Ibbcee6ba22f661984cd830717e14c9b35a1fba0a
      Reviewed-on: https://chromium-review.googlesource.com/1172351
      Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55121}
      de3f3cf0
    • Benedikt Meurer's avatar
      [turbofan] Further optimize DataView accesses. · 5fecd146
      Benedikt Meurer authored
      This adds support for unaligned load/store access to the DataView
      backing store and uses byteswap operations to fix up the endianess
      when necessary. This changes the Word32ReverseBytes operator to be
      a required operator and adds the missing support on the Intel and
      ARM platforms (on 64-bit platforms the Word64ReverseBytes operator
      is also mandatory now).
      
      This further improves the performance on the dataviewperf.js test
      mentioned in the tracking bug by up to 40%, and at the same time
      reduces the code complexity in the EffectControlLinearizer.
      
      Bug: chromium:225811
      Change-Id: I7c1ec826faf46a144a5a9068f8f815a5fd040997
      Reviewed-on: https://chromium-review.googlesource.com/1174252Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55111}
      5fecd146
    • Leszek Swirski's avatar
      Revert "[turbofan] Further optimize DataView accesses." · 6a62d88e
      Leszek Swirski authored
      This reverts commit c46915b9.
      
      Reason for revert: Disasm failures https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20debug/21727 
      
      Original change's description:
      > [turbofan] Further optimize DataView accesses.
      > 
      > This adds support for unaligned load/store access to the DataView
      > backing store and uses byteswap operations to fix up the endianess
      > when necessary. This changes the Word32ReverseBytes operator to be
      > a required operator and adds the missing support on the Intel and
      > ARM platforms (on 64-bit platforms the Word64ReverseBytes operator
      > is also mandatory now).
      > 
      > This further improves the performance on the dataviewperf.js test
      > mentioned in the tracking bug by up to 40%, and at the same time
      > reduces the code complexity in the EffectControlLinearizer.
      > 
      > Bug: chromium:225811
      > Change-Id: I296170b828c2ccc1c317ed37840b564aa14cdec2
      > Reviewed-on: https://chromium-review.googlesource.com/1172777
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#55099}
      
      TBR=sigurds@chromium.org,bmeurer@chromium.org
      
      Change-Id: If7a62e3a1a4ad26823fcbd2ab6eb4c053ad11c49
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:225811
      Reviewed-on: https://chromium-review.googlesource.com/1174171Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55107}
      6a62d88e
  26. 13 Aug, 2018 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Further optimize DataView accesses. · c46915b9
      Benedikt Meurer authored
      This adds support for unaligned load/store access to the DataView
      backing store and uses byteswap operations to fix up the endianess
      when necessary. This changes the Word32ReverseBytes operator to be
      a required operator and adds the missing support on the Intel and
      ARM platforms (on 64-bit platforms the Word64ReverseBytes operator
      is also mandatory now).
      
      This further improves the performance on the dataviewperf.js test
      mentioned in the tracking bug by up to 40%, and at the same time
      reduces the code complexity in the EffectControlLinearizer.
      
      Bug: chromium:225811
      Change-Id: I296170b828c2ccc1c317ed37840b564aa14cdec2
      Reviewed-on: https://chromium-review.googlesource.com/1172777
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55099}
      c46915b9
  27. 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
  28. 21 Jun, 2018 1 commit
  29. 19 Jun, 2018 1 commit
  30. 05 Jun, 2018 1 commit
  31. 04 Jun, 2018 1 commit
  32. 28 May, 2018 1 commit
  33. 26 Apr, 2018 3 commits
  34. 27 Feb, 2018 1 commit
    • Mike Stanton's avatar
      Reland "[turbofan] Masking/poisoning in codegen (optimized code, arm64)" · 7c51c944
      Mike Stanton authored
      This is a reland of 800daded.
      
      Original change's description:
      > [turbofan] Masking/poisoning in codegen (optimized code, arm64)
      > 
      > This introduces masking of loads with speculation bit during code generation.
      > At the moment, this is done only under the
      > --branch-load-poisoning flag, and this CL enlarges the set of supported
      > platforms from {x64, arm} to {x64, arm, arm64}.
      > 
      > Overview of changes:
      > - new register configuration configuration with one register reserved for
      >   the speculation poison/mask (kSpeculationPoisonRegister).
      > - in codegen, we introduce an update to the poison register at the starts
      >   of all successors of branches (and deopts) that are marked as safety
      >   branches (deopts).
      > - in memory optimizer, we lower all field and element loads to PoisonedLoads.
      > - poisoned loads are then masked in codegen with the poison register.
      >   * only integer loads are masked at the moment.
      > 
      > Bug: chromium:798964
      > Change-Id: Ie6bc9c3bdac9998b0ef81f050a9c844399ca3ae4
      > Reviewed-on: https://chromium-review.googlesource.com/928724
      > Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      > Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#51576}
      
      Bug: chromium:798964
      Change-Id: I6c87d34c4e05fca0bd7f5447555133ecb0fb7a2e
      Reviewed-on: https://chromium-review.googlesource.com/939402Reviewed-by: 's avatarMartyn Capewell <martyn.capewell@arm.com>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51602}
      7c51c944
  35. 26 Feb, 2018 1 commit
    • Adam Klein's avatar
      Revert "[turbofan] Masking/poisoning in codegen (optimized code, arm64)" · 797d3df0
      Adam Klein authored
      This reverts commit 800daded.
      
      Reason for revert: breaks arm64 build
      
      Original change's description:
      > [turbofan] Masking/poisoning in codegen (optimized code, arm64)
      > 
      > This introduces masking of loads with speculation bit during code generation.
      > At the moment, this is done only under the
      > --branch-load-poisoning flag, and this CL enlarges the set of supported
      > platforms from {x64, arm} to {x64, arm, arm64}.
      > 
      > Overview of changes:
      > - new register configuration configuration with one register reserved for
      >   the speculation poison/mask (kSpeculationPoisonRegister).
      > - in codegen, we introduce an update to the poison register at the starts
      >   of all successors of branches (and deopts) that are marked as safety
      >   branches (deopts).
      > - in memory optimizer, we lower all field and element loads to PoisonedLoads.
      > - poisoned loads are then masked in codegen with the poison register.
      >   * only integer loads are masked at the moment.
      > 
      > Bug: chromium:798964
      > Change-Id: Ie6bc9c3bdac9998b0ef81f050a9c844399ca3ae4
      > Reviewed-on: https://chromium-review.googlesource.com/928724
      > Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      > Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#51576}
      
      TBR=rmcilroy@chromium.org,mvstanton@chromium.org,mstarzinger@chromium.org,jarin@chromium.org,rodolph.perfetta@arm.com,martyn.capewell@arm.com,pierre.langlois@arm.com
      
      Change-Id: I1b5dad27f9620c7da3277602081f392de6221caf
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:798964
      Reviewed-on: https://chromium-review.googlesource.com/937861Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51578}
      797d3df0