1. 10 Jul, 2020 1 commit
  2. 28 Feb, 2020 1 commit
  3. 14 Nov, 2019 1 commit
  4. 05 Nov, 2019 1 commit
    • Georgia Kouveli's avatar
      [instruction-scheduler] Add a RandomNumberGenerator to InstructionScheduler · 6be9ac9d
      Georgia Kouveli authored
      When running the tests with --turbo-stress-instruction-scheduling, there are
      crashes in the cases where there is no isolate, since we used the random
      generator from the isolate. This change introduces a RandomNumberGenerator to
      the instruction scheduler instead.
      
      We use the value from --random-seed for seeding the random number generator.
      We don't treat a zero value specially, as the feature is meant to be used with
      the test system which always sets a random seed and doesn't rely on default
      behaviour. This also means that the instruction scheduler will always produce
      the same result for the same input within the same run, which fixes another
      issue with the x64 jump optimisation: when that optimisation is enabled, the
      backend is ran twice, and previously it was producing a different schedule
      each time, thus collecting incorrect jump information.
      
      Bug: v8:9884
      Change-Id: I00394a7e50d0c502254b18490ebaf28a38d8f819
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1895555Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
      Cr-Commit-Position: refs/heads/master@{#64769}
      6be9ac9d
  5. 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
  6. 21 Oct, 2019 1 commit
  7. 12 Sep, 2019 1 commit
  8. 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
  9. 11 Jul, 2019 2 commits
  10. 22 May, 2019 1 commit
  11. 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
  12. 12 Nov, 2018 1 commit
  13. 19 Jun, 2018 1 commit
  14. 15 Jun, 2018 1 commit
  15. 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
  16. 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
  17. 21 Mar, 2018 3 commits
  18. 20 Mar, 2018 1 commit
  19. 19 Mar, 2018 1 commit
    • Georgia Kouveli's avatar
      [instruction scheduler] Fix issue with block terminators and deopts. · a33353a0
      Georgia Kouveli authored
      Remove IsBlockTerminator and introduce InstructionScheduler::AddTerminator in
      order to handle block terminator instructions.
      
      Instead of the kBlockTerminator flags, we now rely on Instruction::IsTrap(),
      Instruction::IsDeoptimizeCall() and explicitly denoting block terminators
      when adding them with InstructionScheduler::AddTerminator().
      
      IsBlockTerminator incorrectly included deopts when they were not at the end of
      a block, which meant that an instruction with side effects could have been
      reordered with respect to a deopt as the deopt was not identified correctly.
      
      Since the snapshot does not contain deopts, this is not causing any problems
      at the moment (the scheduler is only enabled on the snapshot).
      
      Change-Id: I1c2dad748a9398a3355630d9a542f4ac89afaa42
      Reviewed-on: https://chromium-review.googlesource.com/960501Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
      Cr-Commit-Position: refs/heads/master@{#52019}
      a33353a0
  20. 23 Feb, 2018 1 commit
  21. 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
  22. 16 Jan, 2018 1 commit
  23. 02 Jan, 2018 1 commit
  24. 12 Dec, 2017 1 commit
  25. 21 Nov, 2017 1 commit
  26. 25 Sep, 2017 1 commit
  27. 24 Aug, 2017 1 commit
  28. 21 Aug, 2017 1 commit
  29. 27 Jul, 2017 1 commit
  30. 20 Jul, 2017 1 commit
  31. 02 Jun, 2017 1 commit
  32. 30 May, 2017 1 commit
    • rodolph.perfetta's avatar
      [instruction scheduler] fix ArchDebugBreak. · f56a48e8
      rodolph.perfetta authored
      In TurboFan the ArchDebugBreak opcode is not used for debugging but to
      force a crash in unreachable or unimplemented code path. The opcode was
      marked as having no side effects allowing the scheduler to bring it "up"
      with unfortunate consequences.
      
      This patch also update the behaviour of assembler::debug when not using
      the simulator.
      
      Review-Url: https://codereview.chromium.org/2901383004
      Cr-Commit-Position: refs/heads/master@{#45608}
      f56a48e8
  33. 22 May, 2017 1 commit
  34. 11 Apr, 2017 1 commit
  35. 16 Mar, 2017 1 commit
  36. 07 Mar, 2017 1 commit