1. 16 Oct, 2020 3 commits
  2. 22 Sep, 2020 1 commit
  3. 28 Feb, 2020 1 commit
  4. 21 Feb, 2020 1 commit
  5. 13 Dec, 2019 1 commit
  6. 15 Nov, 2019 1 commit
  7. 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
  8. 23 Oct, 2019 1 commit
    • Michael Starzinger's avatar
      [turbofan] Change {InstructionCode} to uint32_t. · d5ef741f
      Michael Starzinger authored
      The {InstructionCode} is only used to store plain (non-negative) values
      of the {ArchOpcode} enum, or additionally encodes {BitField} values. The
      underlying base type 'U' of a {BitField} is uint32_t. To avoid all the
      numerous implicit conversions between int32_t and uint32_t, this is
      changing the {InstructionCode} so that uint32_t is used exclusively.
      
      R=neis@chromium.org
      BUG=v8:9872
      
      Change-Id: If64107ad9298011e219b4827735eafb51465beb0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869193Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64503}
      d5ef741f
  9. 12 Aug, 2019 2 commits
    • Jakob Gruber's avatar
      [compiler] Remove LoadStackPointer and related machinery · 5b2ab2f6
      Jakob Gruber authored
      Now that all uses of LoadStackPointer have been removed, this CL cleans
      up related code:
      
      - Removed LoadStackPointer.
      - Removed ArchStackPointer.
      - Removed IA32StackCheck.
      - Removed X64StackCheck.
      - Removed StackCheckMatcher.
      
      All stack checks now follow a simple path without matchers or special
      register constraints: they load the limit and pass it to
      StackPointerGreaterThan, which is finally handled by code generation.
      
      Bug: v8:9534
      Change-Id: Ib1d7be1502a471541d6441f3261aac0c949525fb
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748737
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63166}
      5b2ab2f6
    • Jakob Gruber's avatar
      [compiler] Refactor stack check handling · 0aa204fe
      Jakob Gruber authored
      This CL unifies how stack checks are handled in the Turbofan pipeline
      across architectures, in preparation for properly handling stack
      overflows caused by deoptimization in follow-up work. It will also
      open up possibilities to simplify related logic.
      
      How this used to work: JSStackCheck was lowered to a UintLessThan
      with the stack pointer (sp) and stack limit as inputs. On x64 and ia32,
      this node pattern was later recognized during instruction selection
      and rewritten to dedicated operators. On other platforms, including
      arm and arm64, special logic exists to avoid useless
      register-to-register moves when accessing the sp.
      
      This CL introduces a new StackPointerGreaterThan operator, which takes
      the stack limit as its sole input. This is what JSStackCheck now lowers
      to. This is threaded through to code generation, where we emit the
      appropriate code (in the future, we will apply an additional offset to
      the sp here).
      
      In follow-up CLs, we can remove or replace remaining uses of
      LoadStackPointer in CSA, Wasm, and the interpreter; and then remove
      the LoadStackPointer operator, related node matchers, related register
      constraints, and the pseudo-smi stack limit roots.
      
      Bug: v8:9534
      Change-Id: I0e3f1beeed65b163c4ee5787600bed8c3cc671e1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1738863Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63156}
      0aa204fe
  10. 11 Jul, 2019 2 commits
  11. 23 May, 2019 1 commit
  12. 07 May, 2019 1 commit
  13. 01 Apr, 2019 1 commit
  14. 29 Mar, 2019 1 commit
  15. 25 Mar, 2019 2 commits
  16. 14 Mar, 2019 1 commit
  17. 17 Dec, 2018 1 commit
    • Jakob Gruber's avatar
      [nojit] Add a kCallBuiltinPointer call kind · f323a5f4
      Jakob Gruber authored
      Currently, Torque's builtin pointers store a Code target underneath and
      callsites generate a kArchCallCodeObject opcode. When embedded builtins
      are enabled, the call thus first calls the on-heap trampoline, which
      finally jumps to the target off-heap builtin code.
      
      This will no longer be possible in jitless mode, since on-heap code must
      not be executable.
      
      As a step towards changing the way builtin pointers are called
      (function pointers will hold the builtin index as a Smi, and callsites
      look up the off-heap target address and jump there), this CL adds a
      dedicated opcode for builtin pointer calls to the compiler pipeline.
      
      The calling mechanism itself is unchanged, changes there will happen
      in a follow-up.
      
      Drive-by: rename 'FunctionPointer' in torque/ to 'BuiltinPointer'.
      
      Bug: v8:7777
      Change-Id: Ic999a1cd7c3172425dd4a1513ae2f50c774faddb
      Reviewed-on: https://chromium-review.googlesource.com/c/1378175Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58281}
      f323a5f4
  18. 12 Nov, 2018 1 commit
  19. 19 Jun, 2018 1 commit
  20. 15 Jun, 2018 1 commit
  21. 30 Apr, 2018 1 commit
    • Jaroslav Sevcik's avatar
      Replace array index masking with the poisoning approach. · f53dfd93
      Jaroslav Sevcik authored
      The idea is to mark all the branches and loads participating in array
      bounds checks, and let them contribute-to/use the poisoning register.
      In the code, the marks for array indexing operations now contain
      "Critical" in their name. By default (--untrusted-code-mitigations),
      we only instrument the "critical" operations with poisoning.
      
      With that in place, we also remove the array masking approach based
      on arithmetic.
      
      Since we do not propagate the poison through function calls,
      we introduce a node for poisoning an index that is passed through
      function call - the typical example is the bounds-checked index
      that is passed to the CharCodeAt builtin.
      
      Most of the code in this CL is threads through the three levels of
      protection (safe, critical, unsafe) for loads, branches and flags.
      
      Bug: chromium:798964
      
      Change-Id: Ief68e2329528277b3ba9156115b2a6dcc540d52b
      Reviewed-on: https://chromium-review.googlesource.com/995413
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52883}
      f53dfd93
  22. 27 Mar, 2018 1 commit
    • Tobias Tebbi's avatar
      [turbofan] unify interpreter and JIT speculation poisoning · 1ef6c437
      Tobias Tebbi authored
      This CL changes the poisoning in the interpreter to use the
      infrastructure used in the JIT.
      
      This does not change the original flag semantics:
      
      --branch-load-poisoning enables JIT mitigations as before.
      
      --untrusted-code-mitigation enables the interpreter mitigations
        (now realized using the compiler back-end), but does not enable
        the back-end based mitigations for the Javascript JIT. So in effect
        --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers
        use the same mechanics (including changed register allocation) that
        --branch-load-poisoning enables for the JIT.
      
      Bug: chromium:798964
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27
      Reviewed-on: https://chromium-review.googlesource.com/928881Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52243}
      1ef6c437
  23. 20 Mar, 2018 1 commit
  24. 23 Feb, 2018 1 commit
  25. 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
  26. 02 Jan, 2018 1 commit
  27. 12 Dec, 2017 1 commit
  28. 21 Nov, 2017 1 commit
  29. 24 Aug, 2017 1 commit
  30. 21 Aug, 2017 1 commit
  31. 20 Jul, 2017 1 commit
  32. 18 Jul, 2017 1 commit
  33. 11 Apr, 2017 1 commit
  34. 16 Mar, 2017 1 commit
  35. 07 Mar, 2017 1 commit