1. 08 Jan, 2021 2 commits
  2. 21 Dec, 2020 1 commit
  3. 17 Dec, 2020 3 commits
    • Sathya Gunasekaran's avatar
      [runtime] Use range checks for function instance type checks · cce533ba
      Sathya Gunasekaran authored
      This allows the JSFunctionOrBoundFunction instance type range to no
      longer be stuck at the last of the JSObject instance type range. This
      will be useful in the future where we extend the function instance
      types and include them in fast protector cell checks.
      
      Bug: v8:11256
      Change-Id: I955991576b3cca76b10f76c87748016fe527e3d0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595275Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71826}
      cce533ba
    • Nico Hartmann's avatar
      Revert "Faster JS-to-Wasm calls" · de50785e
      Nico Hartmann authored
      This reverts commit 860fcb1b.
      
      Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm%20-%20sim%20-%20lite/13831/overview
      
      Original change's description:
      > Faster JS-to-Wasm calls
      >
      > This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/.
      >
      > Currently JS-to-Wasm calls go through a wrapper/trampoline, built on
      > the basis of the signature of a Wasm function to call, and whose task
      > is to:
      > - set "thread_in_wasm_flag" to true
      > - convert the arguments from tagged types into Wasm native types
      > - calculate the address of the Wasm function to call and call it
      > - convert back the result from Wasm native types into tagged types
      > - reset "thread_in_wasm_flag" to false.
      >
      > This CL tries to improve the performance of JS-to-Wasm calls by
      > inlining the code of the JS-to-Wasm wrappers in the call site.
      >
      > It introduces a new IR operand, JSWasmCall, which replaces JSCall for
      > this kind of calls. A 'JSWasmCall' node is associated to
      > WasmCallParameters, which contain information about the signature of
      > the Wasm function to call.
      >
      > WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid generating code to convert the types for the arguments
      > of the Wasm function, when the conversion is not necessary.
      > The actual inlining of the graph generated for this wrapper happens in
      > the simplified-lowering phase.
      >
      > A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage
      > lazy deoptimizations that can happen if the Wasm function callee calls
      > back some JS code that invalidates the compiled JS caller function.
      >
      > Bug: v8:11092
      > Change-Id: I3174c1c1f59b39107b333d1929ecc0584486b8ad
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557538
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Reviewed-by: Georg Neis (ooo until January 5) <neis@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Maya Lekova <mslekova@chromium.org>
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      > Cr-Commit-Position: refs/heads/master@{#71824}
      
      TBR=neis@chromium.org,ahaas@chromium.org,jgruber@chromium.org,tebbi@chromium.org,ishell@chromium.org,mslekova@chromium.org,nicohartmann@chromium.org,paolosev@microsoft.com
      
      Change-Id: I214cbdee74c1a2aaad907ffc84662ed25631983e
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:11092
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595438Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71825}
      de50785e
    • Paolo Severini's avatar
      Faster JS-to-Wasm calls · 860fcb1b
      Paolo Severini authored
      This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/.
      
      Currently JS-to-Wasm calls go through a wrapper/trampoline, built on
      the basis of the signature of a Wasm function to call, and whose task
      is to:
      - set "thread_in_wasm_flag" to true
      - convert the arguments from tagged types into Wasm native types
      - calculate the address of the Wasm function to call and call it
      - convert back the result from Wasm native types into tagged types
      - reset "thread_in_wasm_flag" to false.
      
      This CL tries to improve the performance of JS-to-Wasm calls by
      inlining the code of the JS-to-Wasm wrappers in the call site.
      
      It introduces a new IR operand, JSWasmCall, which replaces JSCall for
      this kind of calls. A 'JSWasmCall' node is associated to
      WasmCallParameters, which contain information about the signature of
      the Wasm function to call.
      
      WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid generating code to convert the types for the arguments
      of the Wasm function, when the conversion is not necessary.
      The actual inlining of the graph generated for this wrapper happens in
      the simplified-lowering phase.
      
      A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage
      lazy deoptimizations that can happen if the Wasm function callee calls
      back some JS code that invalidates the compiled JS caller function.
      
      Bug: v8:11092
      Change-Id: I3174c1c1f59b39107b333d1929ecc0584486b8ad
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557538Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarGeorg Neis (ooo until January 5) <neis@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#71824}
      860fcb1b
  4. 03 Dec, 2020 1 commit
    • Leszek Swirski's avatar
      [compiler] Remove disallow scopes · a6f465d4
      Leszek Swirski authored
      TurboFan creates DisallowHeapAccess scopes, to prevent heap access in
      the concurrent parts of the compiler. Then, for parts of the compiler
      that do want to access the heap, it either creates Allow* scopes (which
      should be avoided since they "punch a hole" in the Disallow* scopes), or
      relies on a weakening of Handle::IsDereferenceAllowed which allows
      handles owned by a LocalHeap to be dereferenced even if there is a
      DisallowHeapDereference scope.
      
      This patch:
      
        a) Strengthens the implicit requirements around handle dereferencing
           to require a running heap on this thread (either main-thread heap
           or an un-parked, un-safepointed LocalHeap).
        b) Removes the overly strict Disallow scopes in TurboFan, relying
           instead on implicit requirements for allocation/handle
           dereferencing in off-thread code.
        c) Cleans up the "should_disallow_heap_access" predicate to be more
           explicit about what should be disallowed (e.g. property accesses
           can't be computed concurrently)
      
      Change-Id: Icb56b7764913ac17e2db197a70bb189af88a6978
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2554617
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71600}
      a6f465d4
  5. 26 Nov, 2020 1 commit
  6. 10 Nov, 2020 2 commits
  7. 09 Nov, 2020 5 commits
  8. 07 Nov, 2020 1 commit
  9. 06 Nov, 2020 1 commit
  10. 05 Nov, 2020 2 commits
  11. 28 Oct, 2020 1 commit
  12. 20 Oct, 2020 1 commit
  13. 14 Oct, 2020 1 commit
    • Jakob Gruber's avatar
      Reland "[nci] Prepare JSForInPrepare and JSForInNext for feedback input" · d5a80ba4
      Jakob Gruber authored
      This is a reland of 16cd5995
      
      Changes since the original CL: generic lowering support for ForInPrepare
      and ForInNext.
      
      Original change's description:
      > [nci] Prepare JSForInPrepare and JSForInNext for feedback input
      >
      > These two operators are still missing feedback collection in generic
      > lowering (reminder: all operations that collect FB in the interpreter
      > must also collect FB in generic lowering).
      >
      > This CL prepares for that by adding the feedback vector as an input,
      > and additionally adds node wrappers to improve useability.
      >
      > The actual collection logic will be added in a following CL.
      >
      > Bug: v8:8888
      > Change-Id: I04627eedb2dc237dc4e417091c44d2a95bd98f5f
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2454712
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70372}
      
      Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
      Bug: v8:8888
      Change-Id: Idc294ffd2a24922edd08db6897d32d5724956995
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2459373
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70496}
      d5a80ba4
  14. 07 Oct, 2020 2 commits
  15. 06 Oct, 2020 1 commit
  16. 30 Sep, 2020 1 commit
    • Jakob Gruber's avatar
      [turboprop] Add TURBOPROP code kind · 75b8c238
      Jakob Gruber authored
      Turboprop-generated Code objects will now have the dedicated
      TURBOPROP code kind instead of OPTIMIZED_FUNCTION. When possible,
      the code kind is used as the source of truth instead of
      FLAG_turboprop. This is the initial step towards implementing
      tier-up from Turboprop to Turbofan.
      
      Future work: Rename OPTIMIZED_FUNCTION to TURBOFAN, rename STUB to
      DEOPT_ENTRIES_OR_FOR_TESTING, implement TP tier-up.
      
      No-Try: true
      Bug: v8:9684
      Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
      Change-Id: I3c9308718d7e9a2b7e6796e7ea94f17e5ff84c0a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424140
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70213}
      75b8c238
  17. 29 Sep, 2020 2 commits
  18. 28 Sep, 2020 1 commit
  19. 16 Sep, 2020 1 commit
  20. 15 Sep, 2020 2 commits
  21. 31 Aug, 2020 1 commit
  22. 24 Aug, 2020 1 commit
    • Jakob Gruber's avatar
      Improve usability of GraphAssembler's Unreachable() · e02e5107
      Jakob Gruber authored
      Prior to this CL, one had to artificially insert a
      basic-block-terminating node after Unreachable. The common pattern was
      
       Unreachable();
       Goto(&some_label);  // Never reached but generates useless code.
      
      This CL improves usability by automatically merging Unreachable nodes
      to the end node, and terminating current effect/control. The updated
      pattern is just
      
       Unreachable();
      
      or in cases where Turboprop must maintain a schedule:
      
       Unreachable(&some_label);
      
      Bug: v8:8888
      Change-Id: I26a0b11b5e67252a6dc3584ae09ed06370f1eacc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362690
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69531}
      e02e5107
  23. 29 Jul, 2020 1 commit
  24. 22 Jul, 2020 2 commits
  25. 15 Jul, 2020 1 commit
  26. 09 Jul, 2020 1 commit
  27. 07 Jul, 2020 1 commit
    • Jakob Gruber's avatar
      [nci] Don't expose feedback to compiler phases in NCI mode · e33e8481
      Jakob Gruber authored
      Native context independent code generation should, at the moment, not
      use any collected feedback.
      
      We implement this by returning InsufficientFeedback from the heap
      broker's ReadFeedbackForX methods if currently compiling nci code.
      Thus all feedback.IsInsufficient() calls inside the compiler will
      return true (disabling feedback-based optimizations).
      FeedbackSource::IsValid() (used in generic lowering) can still return
      true.
      
      Bug: v8:8888
      Change-Id: I198b6457276073e7376c777b206c50726f1b3645
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2284494
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68726}
      e33e8481