1. 12 Feb, 2021 1 commit
  2. 02 Dec, 2020 1 commit
  3. 01 Dec, 2020 1 commit
    • Ross McIlroy's avatar
      [Turboprop] Move deoptimizations for dynamic map checks into builtin. · b6643320
      Ross McIlroy authored
      In order to reduce the codegen size of dynamic map checks, add the
      ability to have an eager with resume deopt point, which can call
      a given builitin to perform a more detailed check than can be done
      in codegen, and then either deoptimizes itself (as if the calling
      code had performed an eager deopt) or resumes execution in the
      calling code after the check.
      
      In addition, support for adding extra arguments to a
      deoptimization continuation is added to enable us to pass the
      necessary arguments to the DynamicMapChecks builtin.
      
      Finally, a trampoline is added to the DynamicMapChecks which saves
      the registers that might be clobbered by that builtin, to avoid
      having to save them in the generated code. This trampoline also
      performs the deoptimization based on the result of the
      DynamicMapChecks builtin.
      
      In order to ensure both the trampoline and DynamicMapChecks
      builtin have the same call interface, and to limit the number
      of registers that need saving in the trampoline, the
      DynamicMapChecks builtin is moved to be a CSA builtin with a
      custom CallInterfaceDescriptor, that calls an exported Torque
      macro that implements the actual functionality.
      
      All told, this changes the codegen for a monomorphic dynamic
      map check from:
          movl rbx,<expected_map>
          cmpl [<object>-0x1],rbx
          jnz <deferred_call>
         resume_point:
          ...
         deferred_call:
          <spill registers>
          movl rax,<slot>
          movq rbx,<object>
          movq rcx,<handler>
          movq r10,<DynamicMapChecks>
          call r10
          cmpq rax,0x0
          jz <restore_regs>
          cmpq rax,0x1
          jz <deopt_point_1>
          cmpq rax,0x2
          jz <deopt_point_2>
          int3l
         restore_regs:
          <restore_regs>
          jmp <resume_point>
          ...
         deopt_point_1:
          call Deoptimization_Eager
         deopt_point_2:
          call Deoptimization_Bailout
      
      To: movl rax,<slot>
          movl rcx,<expected_map>
          movq rdx,<handler>
          cmpl [<object>-0x1],rcx
          jnz <deopt_point>
         resume_point:
          ...
         deopt_point:
          call DynamicMapChecksTrampoline
          jmp <resume_point>
      
      BUG=v8:10582
      
      Change-Id: Ica4927b9acc963b9b73dc62d9379a7815335650f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2560197
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71545}
      b6643320
  4. 15 Oct, 2020 1 commit
  5. 30 Sep, 2020 1 commit
  6. 27 Aug, 2020 1 commit
  7. 22 Oct, 2019 1 commit
  8. 23 May, 2019 1 commit
  9. 21 May, 2019 1 commit
  10. 14 Feb, 2019 1 commit
    • Benedikt Meurer's avatar
      [v8-extras] Harden `resolvePromise()` and `rejectPromise()`. · aa00ee22
      Benedikt Meurer authored
      The V8 Extras API provides `resolvePromise()` and `rejectPromise()`
      functions that bypass the safety net of the resolve/reject closures
      that you get from using the Promise constructor. So it's the
      responsibility of the user to make sure that the promises are still
      pending. This adds release mode checking and hard aborts to make
      sure we catch misuse of these APIs early.
      
      This also turns the DCHECK's in the C++ implementation into actual
      CHECK's to make sure we crash hard if the invariants are violated.
      
      Bug: chromium:931949, chromium:931640
      Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
      Change-Id: I98a6f424d2a3cfbb608fed21036caff6e2510ec3
      Reviewed-on: https://chromium-review.googlesource.com/c/1472291Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59610}
      aa00ee22
  11. 19 Dec, 2018 3 commits
  12. 12 Dec, 2018 1 commit
  13. 10 Dec, 2018 1 commit
  14. 06 Nov, 2018 1 commit
  15. 24 Aug, 2018 1 commit
  16. 24 Jul, 2018 1 commit
    • Clemens Hammacher's avatar
      Reland "[turboassembler] Introduce hard-abort mode" · d324382e
      Clemens Hammacher authored
      This is a reland of a462a785
      
      Original change's description:
      > [turboassembler] Introduce hard-abort mode
      > 
      > For checks and assertions (mostly for debug code, like stack alignment
      > or zero extension), we had two modes: Emit a call to the {Abort}
      > runtime function (the default), and emit a debug break (used for
      > testing, enabled via --trap-on-abort).
      > In wasm, where we cannot just call a runtime function because code must
      > be isolate independent, we always used the trap-on-abort behaviour.
      > This causes problems for our fuzzers, which do not catch SIGTRAP, and
      > hence do not detect debug code failures.
      > 
      > This CL introduces a third mode ("hard abort"), which calls a C
      > function via {ExternalReference}. The C function still outputs the
      > abort reason, but does not print the stack trace. It then aborts via
      > "OS::Abort", just like the runtime function.
      > This will allow fuzzers to detect the crash and even find a nice error
      > message.
      > 
      > Even though this looks like a lot of code churn, it is actually not.
      > Most added lines are new tests, and other changes are minimal.
      > 
      > R=mstarzinger@chromium.org
      > 
      > Bug: chromium:863799
      > Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
      > Reviewed-on: https://chromium-review.googlesource.com/1142163
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#54592}
      
      Bug: chromium:863799
      Change-Id: I7729a47b4823a982a8e201df36520aa2b6ef5326
      Reviewed-on: https://chromium-review.googlesource.com/1146100Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54656}
      d324382e
  17. 20 Jul, 2018 4 commits
    • Sigurd Schneider's avatar
      Speculatively revert "[turboassembler] Introduce hard-abort mode" · 039c18e1
      Sigurd Schneider authored
      This reverts commit a462a785.
      
      Reason for revert: Breaks a TurboAssembler test:
      https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Arm/7726
      
      Original change's description:
      > [turboassembler] Introduce hard-abort mode
      > 
      > For checks and assertions (mostly for debug code, like stack alignment
      > or zero extension), we had two modes: Emit a call to the {Abort}
      > runtime function (the default), and emit a debug break (used for
      > testing, enabled via --trap-on-abort).
      > In wasm, where we cannot just call a runtime function because code must
      > be isolate independent, we always used the trap-on-abort behaviour.
      > This causes problems for our fuzzers, which do not catch SIGTRAP, and
      > hence do not detect debug code failures.
      > 
      > This CL introduces a third mode ("hard abort"), which calls a C
      > function via {ExternalReference}. The C function still outputs the
      > abort reason, but does not print the stack trace. It then aborts via
      > "OS::Abort", just like the runtime function.
      > This will allow fuzzers to detect the crash and even find a nice error
      > message.
      > 
      > Even though this looks like a lot of code churn, it is actually not.
      > Most added lines are new tests, and other changes are minimal.
      > 
      > R=​mstarzinger@chromium.org
      > 
      > Bug: chromium:863799
      > Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
      > Reviewed-on: https://chromium-review.googlesource.com/1142163
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#54592}
      
      TBR=mstarzinger@chromium.org,clemensh@chromium.org
      
      Change-Id: I60c011cfe262ccebbb9abf32699a9fe17e72a3c8
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:863799
      Reviewed-on: https://chromium-review.googlesource.com/1145431
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54597}
      039c18e1
    • Sigurd Schneider's avatar
      Revert "[cleanup] Rename {kLastErrorMessage} to {kNumberOfReasons}" · 9741c7e3
      Sigurd Schneider authored
      This reverts commit 29379945.
      
      Reason for revert: Needed for other revert:
      https://chromium-review.googlesource.com/c/v8/v8/+/1145431
      
      Original change's description:
      > [cleanup] Rename {kLastErrorMessage} to {kNumberOfReasons}
      > 
      > The name {kLastErrorMessage} is misleading, as it's not actually the
      > index of the last message (or reason), but one more (i.e. number of
      > messages / reasons). Thus this renaming.
      > 
      > R=​mstarzinger@chromium.org
      > 
      > Bug: v8:7754
      > Change-Id: Id21edcecac84c0e6068423c6124ef2881116dc7c
      > Reviewed-on: https://chromium-review.googlesource.com/1145305
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#54593}
      
      TBR=mstarzinger@chromium.org,clemensh@chromium.org
      
      Change-Id: I2af83f4a2299e05ad9bcacfe69c0b483fd1488de
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7754
      Reviewed-on: https://chromium-review.googlesource.com/1145520Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54596}
      9741c7e3
    • Clemens Hammacher's avatar
      [cleanup] Rename {kLastErrorMessage} to {kNumberOfReasons} · 29379945
      Clemens Hammacher authored
      The name {kLastErrorMessage} is misleading, as it's not actually the
      index of the last message (or reason), but one more (i.e. number of
      messages / reasons). Thus this renaming.
      
      R=mstarzinger@chromium.org
      
      Bug: v8:7754
      Change-Id: Id21edcecac84c0e6068423c6124ef2881116dc7c
      Reviewed-on: https://chromium-review.googlesource.com/1145305
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54593}
      29379945
    • Clemens Hammacher's avatar
      [turboassembler] Introduce hard-abort mode · a462a785
      Clemens Hammacher authored
      For checks and assertions (mostly for debug code, like stack alignment
      or zero extension), we had two modes: Emit a call to the {Abort}
      runtime function (the default), and emit a debug break (used for
      testing, enabled via --trap-on-abort).
      In wasm, where we cannot just call a runtime function because code must
      be isolate independent, we always used the trap-on-abort behaviour.
      This causes problems for our fuzzers, which do not catch SIGTRAP, and
      hence do not detect debug code failures.
      
      This CL introduces a third mode ("hard abort"), which calls a C
      function via {ExternalReference}. The C function still outputs the
      abort reason, but does not print the stack trace. It then aborts via
      "OS::Abort", just like the runtime function.
      This will allow fuzzers to detect the crash and even find a nice error
      message.
      
      Even though this looks like a lot of code churn, it is actually not.
      Most added lines are new tests, and other changes are minimal.
      
      R=mstarzinger@chromium.org
      
      Bug: chromium:863799
      Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
      Reviewed-on: https://chromium-review.googlesource.com/1142163
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54592}
      a462a785
  18. 24 May, 2018 1 commit
    • Jaroslav Sevcik's avatar
      [generators] Store parameters in the generator object. · ea7499f5
      Jaroslav Sevcik authored
      Currently, we context allocate all parameters for generators.
      
      With this CL, we keep arguments on stack (unless they escape to inner
      closure) and copy them between the stack and the generator's register
      file on suspend/resume. This will save context allocation in most cases.
      
      Note: There is an asymmetry between suspend and resume.
      - Suspend copies arguments and registers to the generator.
      - Resume copies only the registers from the generator, the arguments
        are copied by the ResumeGenerator trampoline.
      
      Bug: v8:5164
      Change-Id: I6333898c60abf461b1ab1b5c6d3dc7188fa95649
      Reviewed-on: https://chromium-review.googlesource.com/1063712
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53327}
      ea7499f5
  19. 23 Mar, 2018 1 commit
  20. 22 Mar, 2018 3 commits
  21. 20 Mar, 2018 2 commits
  22. 27 Feb, 2018 1 commit
  23. 02 Feb, 2018 1 commit
  24. 29 Jan, 2018 1 commit
  25. 18 Jan, 2018 1 commit
  26. 04 Jan, 2018 1 commit
  27. 25 Oct, 2017 1 commit
    • Jaroslav Sevcik's avatar
      Revert "[turbofan] Prune control flow based on failed map checks and comparisons." · f3b4841d
      Jaroslav Sevcik authored
      This reverts commit 37b4b2f1.
      
      Reason for revert: Likely breaking canary.
      
      Original change's description:
      > [turbofan] Prune control flow based on failed map checks and comparisons.
      > 
      > This introduces unreachable state into load elimination. We mark state
      > as unreachable if we know statically that a map check would fail.
      > When processing effect phis, we disconnect unreachable state's
      > control from the effect phi's merge, and point it to RuntimeAbort.
      > The control input to the merge is then updated with Dead. Dead
      > code elimination prunes the merge, phis and effect phis.
      > 
      > Bug: v8:6396
      > Change-Id: I01874b576e548747a915c7b645b96ebaa6f6700d
      > Reviewed-on: https://chromium-review.googlesource.com/730754
      > Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#48810}
      
      TBR=jarin@chromium.org,bmeurer@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:6396, chromium:777843
      Change-Id: I6fac6f86e138f33756e688ec30424cb940690dae
      Reviewed-on: https://chromium-review.googlesource.com/737829Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48918}
      f3b4841d
  28. 22 Oct, 2017 1 commit
  29. 19 Oct, 2017 2 commits
    • Jaroslav Sevcik's avatar
      Revert "[turbofan] Load elimination prunes control flow based on instance type." · 8f09a751
      Jaroslav Sevcik authored
      This reverts commit 71bcc1d9.
      
      Reason for revert: Regresses Octane/Box2D, among other things.
      
      Original change's description:
      > [turbofan] Load elimination prunes control flow based on instance type.
      > 
      > Changes:
      > - introduce the notion of unreachable abstract states.
      > 
      > - reconnect unreachables states to runtime abort in effect phis (so that
      >   the merged states are not polluted by unreachable branches while
      >   preserving SSA).
      > 
      > - mark states with failed map checks, unreachable map guars as unreachable.
      > 
      > - add instance type to AbstractMaps, only invalidate instance type on
      >   mismatched effect merges.
      > 
      > 
      > This results in 2-3% improvement on ARES/ML steady state.
      > 
      > Bug: v8:6396
      > Change-Id: I35b0d4482fa400ba7ee9a754f8ef1b2663ebc7dc
      > Reviewed-on: https://chromium-review.googlesource.com/727761
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#48742}
      
      TBR=jarin@chromium.org,bmeurer@chromium.org
      
      Change-Id: I6302b37dbf5ea781c64815ef1900681531ad7d71
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6396
      Reviewed-on: https://chromium-review.googlesource.com/728440Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48763}
      8f09a751
    • Jaroslav Sevcik's avatar
      [turbofan] Load elimination prunes control flow based on instance type. · 71bcc1d9
      Jaroslav Sevcik authored
      Changes:
      - introduce the notion of unreachable abstract states.
      
      - reconnect unreachables states to runtime abort in effect phis (so that
        the merged states are not polluted by unreachable branches while
        preserving SSA).
      
      - mark states with failed map checks, unreachable map guars as unreachable.
      
      - add instance type to AbstractMaps, only invalidate instance type on
        mismatched effect merges.
      
      
      This results in 2-3% improvement on ARES/ML steady state.
      
      Bug: v8:6396
      Change-Id: I35b0d4482fa400ba7ee9a754f8ef1b2663ebc7dc
      Reviewed-on: https://chromium-review.googlesource.com/727761Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48742}
      71bcc1d9
  30. 13 Oct, 2017 2 commits