1. 22 Feb, 2021 1 commit
  2. 05 Feb, 2021 1 commit
    • Paolo Severini's avatar
      [compiler] Re-reland "Faster JS-to-Wasm calls" · 831fa62b
      Paolo Severini authored
      This is a reland of 6ada6a90
      
      - Fixed a GC issue
        https://bugs.chromium.org/p/v8/issues/detail?id=11335:
        GC expected all arguments on the stack from code with
        CodeKind::TURBOFAN to be tagged objects. This is not the case now with
        inlined Wasm calls, and this information can be passed in
        SafepointEntry for each call site.
      
      - Disabled JS-to-Wasm inlining for calls inside try/catch.
      
      For more details, see updated doc:
      https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
      
      Bug: v8:11092
      
      
      Original change's description:
      > Reland "Faster JS-to-Wasm calls"
      >
      > This is a reland of 860fcb1b
      >
      > - Disabled the tests for this feature in V8-lite mode (the original
      > change broke V8-lite tests).
      > - Also modified test console-profile-wasm.js that was brittle with this
      > change because it assumed that there was always a JS-to-Wasm wrapper
      > but this is not the case when the TurboFan compilation completes before
      > the Liftoff-compiled code starts to run.
      >
      > More changes in Patchset 8:
      >
      > - Moved inlining of the "JSToWasm Wrapper" away from simplified-lowering,
      > into a new phase, wasm-inlining that reuses the JSInliner reducer.
      > The doc
      > https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
      > describes the new logic.
      >
      > - Fixed a couple of small issues in wasm_compiler.cc to make sure that
      > the graph "JSToWasm Wrapper" subgraph has a valid Control chain;
      > this should solve the problem we had inlining the calls in functions
      > that can throw exception.
      
      
      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
      Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
      Change-Id: Ie052634598754feab4ff36d10fd04e008b5227a5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649777
      Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72541}
      831fa62b
  3. 22 Jan, 2021 1 commit
    • Paolo Severini's avatar
      Revert "Reland "Faster JS-to-Wasm calls"" · 51ecfaec
      Paolo Severini authored
      This reverts commit 6ada6a90.
      
      Reason for revert: Revert for link issue:
      https://bugs.chromium.org/p/v8/issues/detail?id=11335
      
      Original change's description:
      > Reland "Faster JS-to-Wasm calls"
      >
      > This is a reland of 860fcb1b
      >
      > - Disabled the tests for this feature in V8-lite mode (the original
      > change broke V8-lite tests)
      > - Also modified test console-profile-wasm.js that was brittle with this
      > change because it assumed that there was always a JS-to-Wasm wrapper
      > but this is not the case when the TurboFan compilation completes before
      > the Liftoff-compiled code starts to run.
      >
      > More changes in Patchset 8:
      >
      > - Moved inlining of the "JSToWasm Wrapper" away from simplified-lowering,
      > into a new phase, wasm-inlining that reuses the JSInliner reducer.
      > The doc
      > https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
      > describes the new logic.
      >
      > - Fixed a couple of small issues in wasm_compiler.cc to make sure that
      > the graph "JSToWasm Wrapper" subgraph has a valid Control chain;
      > this should solve the problem we had inlining the calls in functions
      > that can throw exception.
      >
      >
      > 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}
      >
      > Bug: v8:11092
      > Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
      > Change-Id: I7d8523fa916bf4029a31f8c7a72bbd93336dc0b9
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2596784
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Reviewed-by: Maya Lekova <mslekova@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      > Cr-Commit-Position: refs/heads/master@{#72147}
      
      Tbr: ahaas@chromium.org, jgruber@chromium.org
      Bug: v8:11092, v8:11335
      Change-Id: Iab2908928dfe7ea353f70cb5d3bf2de4d3074db6
      Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2644758
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72253}
      51ecfaec
  4. 20 Jan, 2021 1 commit
    • Jakob Gruber's avatar
      [compiler] Rename type BailoutId to BytecodeOffset · 727d22be
      Jakob Gruber authored
      This reflects the actual contents of the type, which is an offset into
      the bytecode (or certain marker values). Historically, in the days of
      FCG the bailout id used to refer to node ids - this is why certain
      tracing output still calls the bailout id 'node id' and 'ast id'.
      These spots will be fixed in a follow-up CL.
      
      This change is mechanical:
      
       git grep -l BailoutId | while read f; do \
        sed -i 's/BailoutId/BytecodeOffset/g' $f; done
      
      With a manual component of updating the DeoptimizationData method
      name from 'BytecodeOffset' to 'GetBytecodeOffset'.
      
      Bug: v8:11332
      Change-Id: I956b947a480bf52263159c0eb1e895360bcbe6d2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639754
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72189}
      727d22be
  5. 19 Jan, 2021 1 commit
    • Paolo Severini's avatar
      Reland "Faster JS-to-Wasm calls" · 6ada6a90
      Paolo Severini authored
      This is a reland of 860fcb1b
      
      - Disabled the tests for this feature in V8-lite mode (the original
      change broke V8-lite tests)
      - Also modified test console-profile-wasm.js that was brittle with this
      change because it assumed that there was always a JS-to-Wasm wrapper
      but this is not the case when the TurboFan compilation completes before
      the Liftoff-compiled code starts to run.
      
      More changes in Patchset 8:
      
      - Moved inlining of the "JSToWasm Wrapper" away from simplified-lowering,
      into a new phase, wasm-inlining that reuses the JSInliner reducer.
      The doc
      https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
      describes the new logic.
      
      - Fixed a couple of small issues in wasm_compiler.cc to make sure that
      the graph "JSToWasm Wrapper" subgraph has a valid Control chain;
      this should solve the problem we had inlining the calls in functions
      that can throw exception.
      
      
      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}
      
      Bug: v8:11092
      Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
      Change-Id: I7d8523fa916bf4029a31f8c7a72bbd93336dc0b9
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2596784Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#72147}
      6ada6a90
  6. 17 Dec, 2020 2 commits
    • 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
  7. 06 Nov, 2020 1 commit
  8. 16 Oct, 2020 3 commits
  9. 01 Sep, 2020 2 commits
    • Seth Brenith's avatar
      Revert "[regalloc] Run SpillPlacer on any value defined in a loop" · 3017f895
      Seth Brenith authored
      This reverts commit 7f054679.
      
      Reason for revert: regressions on Emscripten/Fannkuch and
      JetStream/richards
      
      Original change's description:
      > [regalloc] Run SpillPlacer on any value defined in a loop
      > 
      > I previously wrote a comment that said "We haven't seen any indication
      > of performance improvements from seeking optimal spilling positions
      > except on loop-top phi values". That statement is no longer true, now
      > that I've looked a little harder. In the latest version of the Mono
      > interpreter, we can improve performance by 2.5% by enabling SpillPlacer
      > for any value defined within a loop.
      > 
      > Bug: v8:10606
      > Change-Id: I25e06458c87ad4ffcefe52be3042032e05a47b35
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2381557
      > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Cr-Commit-Position: refs/heads/master@{#69646}
      
      TBR=rmcilroy@chromium.org,seth.brenith@microsoft.com,thibaudm@chromium.org
      
      Change-Id: Ic3e74485f42bafedfe1890c0be32a29c3455afe5
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10606, chromium:1124028
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2388745Reviewed-by: 's avatarSeth Brenith <seth.brenith@microsoft.com>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#69658}
      3017f895
    • Seth Brenith's avatar
      [regalloc] Run SpillPlacer on any value defined in a loop · 7f054679
      Seth Brenith authored
      I previously wrote a comment that said "We haven't seen any indication
      of performance improvements from seeking optimal spilling positions
      except on loop-top phi values". That statement is no longer true, now
      that I've looked a little harder. In the latest version of the Mono
      interpreter, we can improve performance by 2.5% by enabling SpillPlacer
      for any value defined within a loop.
      
      Bug: v8:10606
      Change-Id: I25e06458c87ad4ffcefe52be3042032e05a47b35
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2381557Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#69646}
      7f054679
  10. 18 Aug, 2020 1 commit
  11. 29 Jul, 2020 2 commits
  12. 28 Jul, 2020 1 commit
    • Ross McIlroy's avatar
      [TurboProp] Add reference map population to fast reg alloc. · e9a37bf8
      Ross McIlroy authored
      Adds support for populating reference maps to the fast
      register allocator. In order to calculate whether a stack slot
      is live at a given instruction, we use the dominator tree to
      build a bitmap of blocks which are dominated by each block.
      A variable's spill operand is classed as alive for any blocks that are
      dominated by the block it was defined in, until the instruction index
      of the spill operand's last use. As such, it may be classified as live
      down a branch where the spill operand is never used, however it is safe
      since the spill slot won't be re-allocated until after it's last-use
      instruction index in any case.
      
      BUG=v8:9684
      
      Change-Id: I772374599ef916f57d82d468f66429e32c712ddf
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2298008
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69108}
      e9a37bf8
  13. 24 Jul, 2020 2 commits
  14. 23 Jul, 2020 2 commits
  15. 10 Jul, 2020 1 commit
  16. 14 May, 2020 1 commit
  17. 17 Mar, 2020 1 commit
  18. 05 Mar, 2020 1 commit
    • Dan Elphick's avatar
      [compiler] Optimize AddInputsToFrameStateDescriptor · 500d73b9
      Dan Elphick authored
      Optimizes InstructionSelector::AddInputsToFrameStateDescriptor by
      taking advantage of SparseInputMask data structure to more quickly
      handle empty inputs and insert all the OptimizedOut entries in one go.
      The number of empty inputs is now determined using CountTrailingZeros
      rather than iterating over them one at a time.
      
      Gives a 9% improvement to SelectInstructions runtime call stat for
      Octane in turboprop.
      
      Bug: v8:10051
      Change-Id: Ib13d6f9644b4c89ba0546a19fe0ed623d69fec99
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037443
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66591}
      500d73b9
  19. 13 Dec, 2019 2 commits
  20. 15 Nov, 2019 1 commit
  21. 11 Nov, 2019 1 commit
  22. 31 Oct, 2019 1 commit
  23. 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
  24. 17 Oct, 2019 1 commit
  25. 24 Sep, 2019 1 commit
  26. 10 Sep, 2019 1 commit
  27. 26 Aug, 2019 1 commit
  28. 23 Aug, 2019 2 commits
  29. 22 Aug, 2019 3 commits
    • Jakob Gruber's avatar
      Reland "[compiler] Track the maximal unoptimized frame size" · 95e26e49
      Jakob Gruber authored
      This is a reland of 1e472c42
      
      No change, this was a speculative revert to unblock the roll.
      
      TBR=jgruber
      
      Original change's description:
      > [compiler] Track the maximal unoptimized frame size
      >
      > This is another step towards considering the unoptimized frame size in
      > stack checks within optimized code.
      >
      > With the changes in this CL, we now keep track of the maximal
      > unoptimized frame size of the function that is currently being
      > compiled. An optimized function may inline multiple unoptimized
      > functions, so a single optimized frame can deopt to multiple
      > frames. The real frame size thus differs in different parts of the
      > optimized function.
      >
      > We only care about the maximal frame size, which we calculate
      > conservatively as an over-approximation, and track in
      > InstructionSelector::max_unoptimized_frame_height_ for now. In future
      > work, this value will be passed on to codegen, where it will be
      > applied as an offset to the stack pointer during the stack check.
      >
      > (The motivation behind this is to avoid stack overflows through deopts,
      > caused by size differences between optimized and unoptimized frames.)
      >
      > Note that this offset only ensure that the topmost optimized frame can
      > deopt without overflowing the stack limit. That's fine, because we only
      > deopt optimized frames one at a time. Other (non-topmost) frames are
      > only deoptimized once they are returned to.
      >
      > Drive-by: Print variable and total frame height in --trace-deopt.
      >
      > Bug: v8:9534
      > Change-Id: I821684a9da93bff59c20c8ab226105e7e12d93eb
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762024
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63330}
      
      Bug: v8:9534
      Change-Id: I686f200e7be1f419e23e50789e11607a0b2886d9
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1766645
      Commit-Queue: Bill Budge <bbudge@chromium.org>
      Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63356}
      95e26e49
    • Bill Budge's avatar
      Revert "[compiler] Track the maximal unoptimized frame size" · 98b5c49f
      Bill Budge authored
      This reverts commit 1e472c42.
      
      Reason for revert: Speculative revert, to attempt to fix crashes that block the V8 roll. Example failure run:
      
      https://ci.chromium.org/p/chromium/builders/try/linux-rel/173465
      
      Original change's description:
      > [compiler] Track the maximal unoptimized frame size
      > 
      > This is another step towards considering the unoptimized frame size in
      > stack checks within optimized code.
      > 
      > With the changes in this CL, we now keep track of the maximal
      > unoptimized frame size of the function that is currently being
      > compiled. An optimized function may inline multiple unoptimized
      > functions, so a single optimized frame can deopt to multiple
      > frames. The real frame size thus differs in different parts of the
      > optimized function.
      > 
      > We only care about the maximal frame size, which we calculate
      > conservatively as an over-approximation, and track in
      > InstructionSelector::max_unoptimized_frame_height_ for now. In future
      > work, this value will be passed on to codegen, where it will be
      > applied as an offset to the stack pointer during the stack check.
      > 
      > (The motivation behind this is to avoid stack overflows through deopts,
      > caused by size differences between optimized and unoptimized frames.)
      > 
      > Note that this offset only ensure that the topmost optimized frame can
      > deopt without overflowing the stack limit. That's fine, because we only
      > deopt optimized frames one at a time. Other (non-topmost) frames are
      > only deoptimized once they are returned to.
      > 
      > Drive-by: Print variable and total frame height in --trace-deopt.
      > 
      > Bug: v8:9534
      > Change-Id: I821684a9da93bff59c20c8ab226105e7e12d93eb
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762024
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63330}
      
      TBR=neis@chromium.org,sigurds@chromium.org,jgruber@chromium.org
      
      Change-Id: I7b225c30bfc4e1d958276583f512a1ec5fa2b458
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9534
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1764626Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Commit-Queue: Bill Budge <bbudge@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63350}
      98b5c49f
    • Jakob Gruber's avatar
      [compiler] Track the maximal unoptimized frame size · 1e472c42
      Jakob Gruber authored
      This is another step towards considering the unoptimized frame size in
      stack checks within optimized code.
      
      With the changes in this CL, we now keep track of the maximal
      unoptimized frame size of the function that is currently being
      compiled. An optimized function may inline multiple unoptimized
      functions, so a single optimized frame can deopt to multiple
      frames. The real frame size thus differs in different parts of the
      optimized function.
      
      We only care about the maximal frame size, which we calculate
      conservatively as an over-approximation, and track in
      InstructionSelector::max_unoptimized_frame_height_ for now. In future
      work, this value will be passed on to codegen, where it will be
      applied as an offset to the stack pointer during the stack check.
      
      (The motivation behind this is to avoid stack overflows through deopts,
      caused by size differences between optimized and unoptimized frames.)
      
      Note that this offset only ensure that the topmost optimized frame can
      deopt without overflowing the stack limit. That's fine, because we only
      deopt optimized frames one at a time. Other (non-topmost) frames are
      only deoptimized once they are returned to.
      
      Drive-by: Print variable and total frame height in --trace-deopt.
      
      Bug: v8:9534
      Change-Id: I821684a9da93bff59c20c8ab226105e7e12d93eb
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762024
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63330}
      1e472c42