1. 05 May, 2022 1 commit
  2. 20 Apr, 2022 1 commit
  3. 08 Dec, 2021 1 commit
  4. 10 Jun, 2021 1 commit
  5. 13 Apr, 2021 1 commit
  6. 25 May, 2020 1 commit
    • Ross McIlroy's avatar
      [TurboProp] Don't try to rewire unreachable blocks to end. · f34771f7
      Ross McIlroy authored
      We can't consistently rewire the successor blocks of an unreachable node to
      disconnect them from the graph when we are trying to maintain the schedule.
      Instead simply leave the code there. As a future optimization we could add a
      proper scheduled dead code elimination phase which can deal with this.
      
      As a side-effect, one of the tests sees a int64 DeadValue, so add support for that
      in the instruction selector.
      
      BUG=chromium:1083272,chromium:1083763,chromium:1084953,v8:9684
      
      Change-Id: I69a6feaeef4eae62110392e27ea848b28bccf787
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209061
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67953}
      f34771f7
  7. 04 Mar, 2020 1 commit
  8. 28 Feb, 2020 1 commit
  9. 11 Nov, 2019 1 commit
  10. 30 Oct, 2019 1 commit
    • Jakob Gruber's avatar
      Reland "[compiler] Optionally apply an offset to stack checks" · b875f466
      Jakob Gruber authored
      This is a reland of 4a16305b
      
      The original CL adjust only one part of the stack check, namely the
      comparison of the stack pointer against the stack limit in generated code.
      There is a second part: Runtime::kStackGuard repeats this check to
      distinguish between a stack overflow and an interrupt request.
      
      This second part in runtime must apply the offset just like in generated
      code. It is implemented in this reland by the StackCheckOffset operator
      and a new StackGuardWithGap runtime function.
      
      Original change's description:
      > [compiler] Optionally apply an offset to stack checks
      >
      > The motivation behind this change is that the frame size of an optimized
      > function and its unoptimized version may differ, and deoptimization
      > may thus trigger a stack overflow. The solution implemented in this CL
      > is to optionally apply an offset to the stack check s.t. the check
      > becomes 'sp - offset > limit'. The offset is applied to stack checks at
      > function-entry, and is set to the difference between the optimized and
      > unoptimized frame size.
      >
      > A caveat: OSR may not be fully handled by this fix since we've already
      > passed the function-entry stack check. A possible solution would be to
      > *not* skip creation of function-entry stack checks for inlinees.
      >
      > This CL: 1. annotates stack check nodes with the stack check kind, where
      > kind is one of {function-entry,iteration-body,unknown}. 2. potentially
      > allocates a temporary register to store the result of the 'sp - offset'
      > in instruction selection (and switches input registers to 'unique'
      > mode). 3. Applies the offset in code generation.
      >
      > Drive-by: Add src/compiler/globals.h for compiler-specific globals.
      >
      > Bug: v8:9534,chromium:1000887
      > Change-Id: I257191c4a4978ccb60cfa5805ef421f30f0e9826
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762521
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63701}
      
      Bug: v8:9534, chromium:1000887
      Change-Id: I71771c281afd7d57c09aa48ea1b182d01e6dee2a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1822037Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64634}
      b875f466
  11. 18 Sep, 2019 1 commit
  12. 12 Sep, 2019 3 commits
    • Jakob Gruber's avatar
      Revert "[compiler] Optionally apply an offset to stack checks" · ba72dc08
      Jakob Gruber authored
      This reverts commit 4a16305b.
      
      Reason for revert: Need to revalidate assumptions behind the CHECK.
      
      Original change's description:
      > [compiler] Optionally apply an offset to stack checks
      > 
      > The motivation behind this change is that the frame size of an optimized
      > function and its unoptimized version may differ, and deoptimization
      > may thus trigger a stack overflow. The solution implemented in this CL
      > is to optionally apply an offset to the stack check s.t. the check
      > becomes 'sp - offset > limit'. The offset is applied to stack checks at
      > function-entry, and is set to the difference between the optimized and
      > unoptimized frame size.
      > 
      > A caveat: OSR may not be fully handled by this fix since we've already
      > passed the function-entry stack check. A possible solution would be to
      > *not* skip creation of function-entry stack checks for inlinees.
      > 
      > This CL: 1. annotates stack check nodes with the stack check kind, where
      > kind is one of {function-entry,iteration-body,unknown}. 2. potentially
      > allocates a temporary register to store the result of the 'sp - offset'
      > in instruction selection (and switches input registers to 'unique'
      > mode). 3. Applies the offset in code generation.
      > 
      > Drive-by: Add src/compiler/globals.h for compiler-specific globals.
      > 
      > Bug: v8:9534,chromium:1000887
      > Change-Id: I257191c4a4978ccb60cfa5805ef421f30f0e9826
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762521
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63701}
      
      TBR=neis@chromium.org,sigurds@chromium.org,jgruber@chromium.org
      
      Change-Id: Iebf46d5256b6dee13451741781ef85a5fe9b1628
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9534, chromium:1000887
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1800565Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63706}
      ba72dc08
    • Georg Neis's avatar
      [compiler] Replace remaining mutable reference arguments · 2304c194
      Georg Neis authored
      Bug: v8:9429
      Change-Id: Id775a765d9700e1d2c46b4598f5e4c8350e28f14
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1796340Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63705}
      2304c194
    • Jakob Gruber's avatar
      [compiler] Optionally apply an offset to stack checks · 4a16305b
      Jakob Gruber authored
      The motivation behind this change is that the frame size of an optimized
      function and its unoptimized version may differ, and deoptimization
      may thus trigger a stack overflow. The solution implemented in this CL
      is to optionally apply an offset to the stack check s.t. the check
      becomes 'sp - offset > limit'. The offset is applied to stack checks at
      function-entry, and is set to the difference between the optimized and
      unoptimized frame size.
      
      A caveat: OSR may not be fully handled by this fix since we've already
      passed the function-entry stack check. A possible solution would be to
      *not* skip creation of function-entry stack checks for inlinees.
      
      This CL: 1. annotates stack check nodes with the stack check kind, where
      kind is one of {function-entry,iteration-body,unknown}. 2. potentially
      allocates a temporary register to store the result of the 'sp - offset'
      in instruction selection (and switches input registers to 'unique'
      mode). 3. Applies the offset in code generation.
      
      Drive-by: Add src/compiler/globals.h for compiler-specific globals.
      
      Bug: v8:9534,chromium:1000887
      Change-Id: I257191c4a4978ccb60cfa5805ef421f30f0e9826
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762521
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63701}
      4a16305b
  13. 10 Sep, 2019 1 commit
  14. 13 Jul, 2019 1 commit
  15. 08 Jul, 2019 1 commit
  16. 31 May, 2019 1 commit
    • Santiago Aboy Solanes's avatar
      [ptr-compr][turbofan][CSA] Adding the CompressedHeapConstant node · a31b36e0
      Santiago Aboy Solanes authored
      CompressedHeapConstant is used in the DecompressionElimination Reducer to
      create compressed HeapConstant values. It won't appear in the graph
      up until that point.
      
      This CL enables back the disabled tests in DecompressionElimination, as
      well as generating the CompressedHeapConstant in that reducer.
      
      The RelocInfo has already been added for x64 but not for arm64. Therefore,
      the x64 version is now doing the mov on 32 bits. The support for ARM will
      come in a following CL, and for now it is doing the mov in 64 bits.
      
      Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng
      Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng
      Bug: v8:8977, v8:7703, v8:9298
      Change-Id: If0ca4f937cfa60501679e66f6fd5ded2df38f605
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632236Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61950}
      a31b36e0
  17. 21 May, 2019 1 commit
  18. 10 May, 2019 1 commit
  19. 13 Mar, 2019 1 commit
  20. 07 Dec, 2018 1 commit
  21. 12 Nov, 2018 1 commit
  22. 04 Oct, 2018 1 commit
  23. 19 Sep, 2018 1 commit
  24. 19 Jun, 2018 1 commit
  25. 09 May, 2018 1 commit
  26. 15 Mar, 2018 1 commit
  27. 09 Mar, 2018 1 commit
  28. 05 Mar, 2018 2 commits
  29. 02 Mar, 2018 3 commits
  30. 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
  31. 26 Feb, 2018 2 commits
    • 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
    • Mike Stanton's avatar
      [turbofan] Masking/poisoning in codegen (optimized code, arm64) · 800daded
      Mike Stanton authored
      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: 's avatarMartyn Capewell <martyn.capewell@arm.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51576}
      800daded
  32. 13 Feb, 2018 1 commit
    • Mike Stanton's avatar
      [turbofan] Masking/poisoning in codegen (optimized code, x64) · 8f489e73
      Mike Stanton authored
      This introduces masking of loads with speculation bit during code generation.
      At the moment, this is done only for x64 optimized code, under the
      --branch-load-poisoning flag.
      
      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: Ie51fdbde578fc289dff029794f3cfe8eaf33e1ef
      Reviewed-on: https://chromium-review.googlesource.com/901625
      Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51272}
      8f489e73
  33. 30 Jan, 2018 1 commit
  34. 04 Jan, 2018 1 commit
    • Tobias Tebbi's avatar
      Reland "[turbofan] add value input to DeadValue" · 6328c565
      Tobias Tebbi authored
      DeadValue was a constant node of type None. This is unsound in the
      presence of re-scheduling. This CL adds a value input to DeadValue,
      which preserves the dependency on the original node of type None.
      
      This reland addresses the bug that the EffectControlLinearizer could destroy dependencies of DeadValue by attaching DeadValue nodes to the effect chain in the EffectControlLinearizer.
      
      Bug: chromium:796041 chromium:798938
      Change-Id: If47b54a7986d257eb63b437f855769b503679ff5
      Reviewed-on: https://chromium-review.googlesource.com/850392Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50360}
      6328c565