1. 12 Feb, 2021 2 commits
    • Ross McIlroy's avatar
      [Turboprop] Ensure constant operands are only used when allowed. · f5305393
      Ross McIlroy authored
      Previously it was possible for a slot operand to be allocated a
      constant operand which is not valid. This CL adds support to the
      mid-tier register allocator to keep track of whether spilled operands
      can support constant operands, and if not to instead move the constant
      to a spill slot at it's definition point, and use that spill slot
      instead.
      
      In the process of doing this, we can cleanup the hack that
      required constants to always be allocated to a register for
      REGISTER_OR_SLOT operator policies.
      
      BUG=chromium:10772,v8:10772,v8:9684
      
      Change-Id: I975ea2c481b45fc0855e175bc6dc2bd0a83f509a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692569Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72722}
      f5305393
    • Georg Neis's avatar
      Reland "[compiler] Directly read PropertyCells" · cf7cba8d
      Georg Neis authored
      This reverts commit 87df0b7e (thus
      relands 42cd9eb7), with fixes for
      the discovered issues.
      
      Original change's description:
      > Revert "[compiler] Directly read PropertyCells"
      >
      > This reverts commit 42cd9eb7.
      >
      > Reason for revert: Clusterfuzz issues, e.g.
      > https://bugs.chromium.org/p/chromium/issues/detail?id=1176318
      >
      > Original change's description:
      > > [compiler] Directly read PropertyCells
      > >
      > > Main changes:
      > >
      > > - Introduce a new broker data kind kBackgroundSerialized for objects
      > >   that can be serialized in the background (when direct reads are on).
      > >   (I'm planning to remove kPossiblyBackgroundSerialized in a followup,
      > >   in favor of a dynamic choice of kSerialized or kBackgroundSerialized).
      > > - Make PropertyCell use that new kind.
      > > - Introduce a bottleneck in runtime code for changes to PropertyCells
      > >   and make sure that a certain protocol is followed that allows
      > >   concurrent reads from the background thread.
      > > - Improve interface of PropertyCell in various ways.
      > >
      > > Bug: v8:7790
      > > Change-Id: If3d7926c3b894808811348b4b2bed153f5c06897
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661462
      > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > > Commit-Queue: Georg Neis <neis@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#72586}
      >
      > TBR=ulan@chromium.org,neis@chromium.org,verwaest@chromium.org,nicohartmann@chromium.org
      >
      > Change-Id: Id04145760c49fa379bc5a3fc16eba664025a9180
      > Bug: v8:7790
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685125
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#72619}
      
      Bug: v8:7790, chromium:1176509, chromium:1176318, chromium:1176504
      Change-Id: Icaf285912bb948432a4a2d599cd174f6a5aa296e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685166Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72697}
      cf7cba8d
  2. 10 Feb, 2021 1 commit
    • Georg Neis's avatar
      Revert "[compiler] Directly read PropertyCells" · 87df0b7e
      Georg Neis authored
      This reverts commit 42cd9eb7.
      
      Reason for revert: Clusterfuzz issues, e.g.
      https://bugs.chromium.org/p/chromium/issues/detail?id=1176318
      
      Original change's description:
      > [compiler] Directly read PropertyCells
      >
      > Main changes:
      >
      > - Introduce a new broker data kind kBackgroundSerialized for objects
      >   that can be serialized in the background (when direct reads are on).
      >   (I'm planning to remove kPossiblyBackgroundSerialized in a followup,
      >   in favor of a dynamic choice of kSerialized or kBackgroundSerialized).
      > - Make PropertyCell use that new kind.
      > - Introduce a bottleneck in runtime code for changes to PropertyCells
      >   and make sure that a certain protocol is followed that allows
      >   concurrent reads from the background thread.
      > - Improve interface of PropertyCell in various ways.
      >
      > Bug: v8:7790
      > Change-Id: If3d7926c3b894808811348b4b2bed153f5c06897
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661462
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#72586}
      
      TBR=ulan@chromium.org,neis@chromium.org,verwaest@chromium.org,nicohartmann@chromium.org
      
      Change-Id: Id04145760c49fa379bc5a3fc16eba664025a9180
      Bug: v8:7790
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685125Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72619}
      87df0b7e
  3. 09 Feb, 2021 1 commit
  4. 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
  5. 26 Jan, 2021 1 commit
    • Paolo Severini's avatar
      [test][turbofan] Add %ObserveNode intrinsic for node-specific tests · 4e9f6513
      Paolo Severini authored
      (Initially copied from nicohartmann@ CL
      https://chromium-review.googlesource.com/c/v8/v8/+/2135631)
      
      This CL adds a new intrinsic %ObserveNode(expr) which has noop semantics
      but triggers the new NodeObserver set on the OptimizedCompilationInfo
      when the node generated for expr is created or changed in any phase
      (until EffectControlLinearization).
      
      This provides the infrastructure to write reasonable unit tests that
      check for the construction of or lowering to specific nodes (e.g.
      depending on feedback).
      
      When %ObserveNode(expr) is used an object of class ObserveNodeManager is
      registered to every Reducer/GraphReducer and is notified by the Reducer
      with all node changes. The same logic is added to classes
      SimplifiedLowering/RepresentationSelector, which do not inherit from
      class Reducer.
      
      Observed Node modifications currently are:
       * The Node Operator
       * The Node type
       * Node replacements
      
      A first use case (cctest/test-sloppy-equality.cc) is included in this CL.
      
      Change-Id: Idc5a5e38af8b1d9a2ec5021bf821c4e4e1406220
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2555219
      Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72331}
      4e9f6513
  6. 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
  7. 21 Jan, 2021 1 commit
  8. 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
  9. 19 Jan, 2021 2 commits
    • Santiago Aboy Solanes's avatar
      [compiler] Unpark local heap for GraphTrimmer::TrimGraph's traces · e16427fa
      Santiago Aboy Solanes authored
      Bug: v8:7790
      Change-Id: I7900d041ff1331991d14e2766a6760b69f37622e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637230Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72172}
      e16427fa
    • 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
  10. 14 Jan, 2021 1 commit
  11. 17 Dec, 2020 1 commit
  12. 15 Dec, 2020 1 commit
  13. 26 Nov, 2020 1 commit
  14. 25 Nov, 2020 1 commit
    • Mythri A's avatar
      [turboprop] Don't use concurrent inlining for TurboFan compilations · 7f15f3e7
      Mythri A authored
      With concurrent inlining, the inlining phase happens on the background
      thread and the data needed for the inlining phase is serialized on
      the main thread. The serialization phase tries to gather data about
      functions called which is sometimes more expensive than inlining phase
      itself. So it's better not to use concurrent inlining for TurboFan
      compilations when tiering up from Turboprop to TurboFan. Turboprop
      compilations don't inline and hence it is OK to continue using
      concurrent inlining for Turboprop compilations.
      
      Bug: v8:9684
      Change-Id: Ib529905213fa7f0df84ee52218adc27f7c219f60
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557504
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71405}
      7f15f3e7
  15. 20 Nov, 2020 2 commits
  16. 19 Nov, 2020 1 commit
    • Dominik Inführ's avatar
      Reland "[heap] Introduce LocalIsolate for main thread" · dc45361e
      Dominik Inführ authored
      This is a reland of e95e1b62
      
      After landing https://crrev.com/c/2546682, this CL can be relanded
      without changes.
      
      Original change's description:
      > [heap] Introduce LocalIsolate for main thread
      >
      > Add a LocalIsolate for the main thread to Isolate. This LocalIsolate is
      > kept alive during the whole lifetime of the Isolate. The main thread
      > LocalIsolate starts in the Running state in contrast to the background
      > thread LocalIsolates (those start in Parked).
      >
      > Code paths in Turbofan that used to create a LocalIsolate on the main
      > thread can now simply use the main thread LocalIsolate.
      >
      > LocalIsolate for the main thread will help in reducing differences
      > between the main and background threads. The goal is that the main
      > thread behaves more like a background thread.
      >
      > The main thread LocalIsolate should also make it simpler to share code
      > between main thread and background threads by using LocalIsolate for
      > both.
      >
      > Bug: v8:10315
      > Change-Id: I7fd61d305a6fd7079e2319d75c291c1021e70018
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2509593
      > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#71226}
      
      Bug: v8:10315
      Change-Id: I418b1217aeac4f3c44a0aa514dea9864f8a58656
      TBR: szuend@chromium.org, yangguo@chromium.org, ulan@chromium.org, leszeks@chromium.org, neis@chromium.org
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2543399Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71274}
      dc45361e
  17. 17 Nov, 2020 2 commits
    • Michael Achenbach's avatar
      Revert "[heap] Introduce LocalIsolate for main thread" · 9235f258
      Michael Achenbach authored
      This reverts commit e95e1b62.
      
      Reason for revert:
      https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm%20-%20sim%20-%20debug/23064
      
      Original change's description:
      > [heap] Introduce LocalIsolate for main thread
      >
      > Add a LocalIsolate for the main thread to Isolate. This LocalIsolate is
      > kept alive during the whole lifetime of the Isolate. The main thread
      > LocalIsolate starts in the Running state in contrast to the background
      > thread LocalIsolates (those start in Parked).
      >
      > Code paths in Turbofan that used to create a LocalIsolate on the main
      > thread can now simply use the main thread LocalIsolate.
      >
      > LocalIsolate for the main thread will help in reducing differences
      > between the main and background threads. The goal is that the main
      > thread behaves more like a background thread.
      >
      > The main thread LocalIsolate should also make it simpler to share code
      > between main thread and background threads by using LocalIsolate for
      > both.
      >
      > Bug: v8:10315
      > Change-Id: I7fd61d305a6fd7079e2319d75c291c1021e70018
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2509593
      > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#71226}
      
      TBR=ulan@chromium.org,yangguo@chromium.org,neis@chromium.org,leszeks@chromium.org,szuend@chromium.org,dinfuehr@chromium.org
      
      Change-Id: Ia70b4bfe3b8fa26bf8d6a7dc612a310b0ed54073
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10315
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2543937Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71228}
      9235f258
    • Dominik Inführ's avatar
      [heap] Introduce LocalIsolate for main thread · e95e1b62
      Dominik Inführ authored
      Add a LocalIsolate for the main thread to Isolate. This LocalIsolate is
      kept alive during the whole lifetime of the Isolate. The main thread
      LocalIsolate starts in the Running state in contrast to the background
      thread LocalIsolates (those start in Parked).
      
      Code paths in Turbofan that used to create a LocalIsolate on the main
      thread can now simply use the main thread LocalIsolate.
      
      LocalIsolate for the main thread will help in reducing differences
      between the main and background threads. The goal is that the main
      thread behaves more like a background thread.
      
      The main thread LocalIsolate should also make it simpler to share code
      between main thread and background threads by using LocalIsolate for
      both.
      
      Bug: v8:10315
      Change-Id: I7fd61d305a6fd7079e2319d75c291c1021e70018
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2509593Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71226}
      e95e1b62
  18. 13 Nov, 2020 1 commit
  19. 06 Nov, 2020 1 commit
  20. 03 Nov, 2020 1 commit
  21. 02 Nov, 2020 1 commit
  22. 29 Oct, 2020 1 commit
  23. 28 Oct, 2020 2 commits
    • Mythri A's avatar
      Reland "[turboprop] Pass required parameters as value inputs to TierUpCheck node" · 71220b3b
      Mythri A authored
      This is a reland of 44f46def with a
      fix for failures with --turbonci_as_mid_tier
      
      Original change's description:
      > [turboprop] Pass required parameters as value inputs to TierUpCheck node
      >
      > TierUpCheck node tail calls interpreter entry trampoline when additional
      > processing is needed for tiering up. Calling IET requires target,
      > new_target, input count and context as parameters. Earlier these were
      > created as parameter nodes in effect-control-linearizer. This causes
      > problems with Turboprop since TurboProp doesn't use the second scheduler
      > and cannot reschedule these nodes to the start block. We should instead
      > create these parameter nodes in bytecode-graph-builder and pass them
      > as value inputs to TierUpCheck node.
      >
      > Bug: v8:9684
      > Change-Id: Icfe5a33b4e628d5a3ba9a3121b2b0746be6aed5c
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2498695
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Commit-Queue: Mythri Alle <mythria@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70790}
      
      Bug: v8:9684
      Change-Id: Ic1a7d39aab0a599d0dd421f237e7bc640fcd6eb1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2504258
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70856}
      71220b3b
    • Mythri A's avatar
      Reland "[turboprop] Add a slot for optimization marker in feedback vector" · c01a36d5
      Mythri A authored
      This is a reland of d7ece57e with
      a fix to failures on NumFuzz.
      
      Original change's description:
      > [turboprop] Add a slot for optimization marker in feedback vector
      >
      > Optimization marker and the optimized code used to share the same slot
      > in the feedback vector as they were mutually exclusive. With turboprop
      > we would want to mark the function for tier up to Turbofan while holding
      > the optimized code for Turboprop. So this cl uses the existing padding
      > field to hold the optimization marker instead.
      >
      > As a driveby, removes unused JSFunction::ClearOptimizedCodeSlot function
      > and fixes a minor bug in Runtime_GetOptimizationStatus.
      >
      > Bug: v8:9684
      > Change-Id: I18c551a69648a0837d16c5453d023c0b295b1521
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467836
      > Commit-Queue: Mythri Alle <mythria@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70789}
      
      Bug: v8:9684
      Change-Id: Ie6aa3c061a852bb047b5921e4e747d43505568e3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2502871
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70834}
      c01a36d5
  24. 27 Oct, 2020 3 commits
  25. 21 Oct, 2020 1 commit
    • Jakob Gruber's avatar
      Reland "Reland "[deoptimizer] Change deopt entries into builtins"" · c7cb9bec
      Jakob Gruber authored
      This is a reland of fbfa9bf4
      
      The arm64 was missing proper codegen for CFI, thus sizes were off.
      
      Original change's description:
      > Reland "[deoptimizer] Change deopt entries into builtins"
      >
      > This is a reland of 7f58ced7
      >
      > It fixes the different exit size emitted on x64/Atom CPUs due to
      > performance tuning in TurboAssembler::Call. Additionally, add
      > cctests to verify the fixed size exits.
      >
      > Original change's description:
      > > [deoptimizer] Change deopt entries into builtins
      > >
      > > While the overall goal of this commit is to change deoptimization
      > > entries into builtins, there are multiple related things happening:
      > >
      > > - Deoptimization entries, formerly stubs (i.e. Code objects generated
      > >   at runtime, guaranteed to be immovable), have been converted into
      > >   builtins. The major restriction is that we now need to preserve the
      > >   kRootRegister, which was formerly used on most architectures to pass
      > >   the deoptimization id. The solution differs based on platform.
      > > - Renamed DEOPT_ENTRIES_OR_FOR_TESTING code kind to FOR_TESTING.
      > > - Removed heap/ support for immovable Code generation.
      > > - Removed the DeserializerData class (no longer needed).
      > > - arm64: to preserve 4-byte deopt exits, introduced a new optimization
      > >   in which the final jump to the deoptimization entry is generated
      > >   once per Code object, and deopt exits can continue to emit a
      > >   near-call.
      > > - arm,ia32,x64: change to fixed-size deopt exits. This reduces exit
      > >   sizes by 4/8, 5, and 5 bytes, respectively.
      > >
      > > On arm the deopt exit size is reduced from 12 (or 16) bytes to 8 bytes
      > > by using the same strategy as on arm64 (recalc deopt id from return
      > > address). Before:
      > >
      > >  e300a002       movw r10, <id>
      > >  e59fc024       ldr ip, [pc, <entry offset>]
      > >  e12fff3c       blx ip
      > >
      > > After:
      > >
      > >  e59acb35       ldr ip, [r10, <entry offset>]
      > >  e12fff3c       blx ip
      > >
      > > On arm64 the deopt exit size remains 4 bytes (or 8 bytes in same cases
      > > with CFI). Additionally, up to 4 builtin jumps are emitted per Code
      > > object (max 32 bytes added overhead per Code object). Before:
      > >
      > >  9401cdae       bl <entry offset>
      > >
      > > After:
      > >
      > >  # eager deoptimization entry jump.
      > >  f95b1f50       ldr x16, [x26, <eager entry offset>]
      > >  d61f0200       br x16
      > >  # lazy deoptimization entry jump.
      > >  f95b2b50       ldr x16, [x26, <lazy entry offset>]
      > >  d61f0200       br x16
      > >  # the deopt exit.
      > >  97fffffc       bl <eager deoptimization entry jump offset>
      > >
      > > On ia32 the deopt exit size is reduced from 10 to 5 bytes. Before:
      > >
      > >  bb00000000     mov ebx,<id>
      > >  e825f5372b     call <entry>
      > >
      > > After:
      > >
      > >  e8ea2256ba     call <entry>
      > >
      > > On x64 the deopt exit size is reduced from 12 to 7 bytes. Before:
      > >
      > >  49c7c511000000 REX.W movq r13,<id>
      > >  e8ea2f0700     call <entry>
      > >
      > > After:
      > >
      > >  41ff9560360000 call [r13+<entry offset>]
      > >
      > > Bug: v8:8661,v8:8768
      > > Change-Id: I13e30aedc360474dc818fecc528ce87c3bfeed42
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465834
      > > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#70597}
      >
      > Tbr: ulan@chromium.org, tebbi@chromium.org, rmcilroy@chromium.org
      > Bug: v8:8661,v8:8768,chromium:1140165
      > Change-Id: Ibcd5c39c58a70bf2b2ac221aa375fc68d495e144
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485506
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70655}
      
      Tbr: ulan@chromium.org, tebbi@chromium.org, rmcilroy@chromium.org
      Bug: v8:8661
      Bug: v8:8768
      Bug: chromium:1140165
      Change-Id: I471cc94fc085e527dc9bfb5a84b96bd907c2333f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2488682Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70672}
      c7cb9bec
  26. 20 Oct, 2020 4 commits
    • Maya Lekova's avatar
      Revert "Reland "[deoptimizer] Change deopt entries into builtins"" · 7c7aa4fa
      Maya Lekova authored
      This reverts commit fbfa9bf4.
      
      Reason for revert: Seems to break arm64 sim CFI build (please see DeoptExitSizeIfFixed) - https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20CFI/2808
      
      Original change's description:
      > Reland "[deoptimizer] Change deopt entries into builtins"
      >
      > This is a reland of 7f58ced7
      >
      > It fixes the different exit size emitted on x64/Atom CPUs due to
      > performance tuning in TurboAssembler::Call. Additionally, add
      > cctests to verify the fixed size exits.
      >
      > Original change's description:
      > > [deoptimizer] Change deopt entries into builtins
      > >
      > > While the overall goal of this commit is to change deoptimization
      > > entries into builtins, there are multiple related things happening:
      > >
      > > - Deoptimization entries, formerly stubs (i.e. Code objects generated
      > >   at runtime, guaranteed to be immovable), have been converted into
      > >   builtins. The major restriction is that we now need to preserve the
      > >   kRootRegister, which was formerly used on most architectures to pass
      > >   the deoptimization id. The solution differs based on platform.
      > > - Renamed DEOPT_ENTRIES_OR_FOR_TESTING code kind to FOR_TESTING.
      > > - Removed heap/ support for immovable Code generation.
      > > - Removed the DeserializerData class (no longer needed).
      > > - arm64: to preserve 4-byte deopt exits, introduced a new optimization
      > >   in which the final jump to the deoptimization entry is generated
      > >   once per Code object, and deopt exits can continue to emit a
      > >   near-call.
      > > - arm,ia32,x64: change to fixed-size deopt exits. This reduces exit
      > >   sizes by 4/8, 5, and 5 bytes, respectively.
      > >
      > > On arm the deopt exit size is reduced from 12 (or 16) bytes to 8 bytes
      > > by using the same strategy as on arm64 (recalc deopt id from return
      > > address). Before:
      > >
      > >  e300a002       movw r10, <id>
      > >  e59fc024       ldr ip, [pc, <entry offset>]
      > >  e12fff3c       blx ip
      > >
      > > After:
      > >
      > >  e59acb35       ldr ip, [r10, <entry offset>]
      > >  e12fff3c       blx ip
      > >
      > > On arm64 the deopt exit size remains 4 bytes (or 8 bytes in same cases
      > > with CFI). Additionally, up to 4 builtin jumps are emitted per Code
      > > object (max 32 bytes added overhead per Code object). Before:
      > >
      > >  9401cdae       bl <entry offset>
      > >
      > > After:
      > >
      > >  # eager deoptimization entry jump.
      > >  f95b1f50       ldr x16, [x26, <eager entry offset>]
      > >  d61f0200       br x16
      > >  # lazy deoptimization entry jump.
      > >  f95b2b50       ldr x16, [x26, <lazy entry offset>]
      > >  d61f0200       br x16
      > >  # the deopt exit.
      > >  97fffffc       bl <eager deoptimization entry jump offset>
      > >
      > > On ia32 the deopt exit size is reduced from 10 to 5 bytes. Before:
      > >
      > >  bb00000000     mov ebx,<id>
      > >  e825f5372b     call <entry>
      > >
      > > After:
      > >
      > >  e8ea2256ba     call <entry>
      > >
      > > On x64 the deopt exit size is reduced from 12 to 7 bytes. Before:
      > >
      > >  49c7c511000000 REX.W movq r13,<id>
      > >  e8ea2f0700     call <entry>
      > >
      > > After:
      > >
      > >  41ff9560360000 call [r13+<entry offset>]
      > >
      > > Bug: v8:8661,v8:8768
      > > Change-Id: I13e30aedc360474dc818fecc528ce87c3bfeed42
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465834
      > > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#70597}
      >
      > Tbr: ulan@chromium.org, tebbi@chromium.org, rmcilroy@chromium.org
      > Bug: v8:8661,v8:8768,chromium:1140165
      > Change-Id: Ibcd5c39c58a70bf2b2ac221aa375fc68d495e144
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485506
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70655}
      
      TBR=ulan@chromium.org,rmcilroy@chromium.org,jgruber@chromium.org,tebbi@chromium.org
      
      Change-Id: I4739a3475bfd8ee0cfbe4b9a20382f91a6ef1bf0
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8661
      Bug: v8:8768
      Bug: chromium:1140165
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485223Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70658}
      7c7aa4fa
    • Jakob Gruber's avatar
      Reland "[deoptimizer] Change deopt entries into builtins" · fbfa9bf4
      Jakob Gruber authored
      This is a reland of 7f58ced7
      
      It fixes the different exit size emitted on x64/Atom CPUs due to
      performance tuning in TurboAssembler::Call. Additionally, add
      cctests to verify the fixed size exits.
      
      Original change's description:
      > [deoptimizer] Change deopt entries into builtins
      >
      > While the overall goal of this commit is to change deoptimization
      > entries into builtins, there are multiple related things happening:
      >
      > - Deoptimization entries, formerly stubs (i.e. Code objects generated
      >   at runtime, guaranteed to be immovable), have been converted into
      >   builtins. The major restriction is that we now need to preserve the
      >   kRootRegister, which was formerly used on most architectures to pass
      >   the deoptimization id. The solution differs based on platform.
      > - Renamed DEOPT_ENTRIES_OR_FOR_TESTING code kind to FOR_TESTING.
      > - Removed heap/ support for immovable Code generation.
      > - Removed the DeserializerData class (no longer needed).
      > - arm64: to preserve 4-byte deopt exits, introduced a new optimization
      >   in which the final jump to the deoptimization entry is generated
      >   once per Code object, and deopt exits can continue to emit a
      >   near-call.
      > - arm,ia32,x64: change to fixed-size deopt exits. This reduces exit
      >   sizes by 4/8, 5, and 5 bytes, respectively.
      >
      > On arm the deopt exit size is reduced from 12 (or 16) bytes to 8 bytes
      > by using the same strategy as on arm64 (recalc deopt id from return
      > address). Before:
      >
      >  e300a002       movw r10, <id>
      >  e59fc024       ldr ip, [pc, <entry offset>]
      >  e12fff3c       blx ip
      >
      > After:
      >
      >  e59acb35       ldr ip, [r10, <entry offset>]
      >  e12fff3c       blx ip
      >
      > On arm64 the deopt exit size remains 4 bytes (or 8 bytes in same cases
      > with CFI). Additionally, up to 4 builtin jumps are emitted per Code
      > object (max 32 bytes added overhead per Code object). Before:
      >
      >  9401cdae       bl <entry offset>
      >
      > After:
      >
      >  # eager deoptimization entry jump.
      >  f95b1f50       ldr x16, [x26, <eager entry offset>]
      >  d61f0200       br x16
      >  # lazy deoptimization entry jump.
      >  f95b2b50       ldr x16, [x26, <lazy entry offset>]
      >  d61f0200       br x16
      >  # the deopt exit.
      >  97fffffc       bl <eager deoptimization entry jump offset>
      >
      > On ia32 the deopt exit size is reduced from 10 to 5 bytes. Before:
      >
      >  bb00000000     mov ebx,<id>
      >  e825f5372b     call <entry>
      >
      > After:
      >
      >  e8ea2256ba     call <entry>
      >
      > On x64 the deopt exit size is reduced from 12 to 7 bytes. Before:
      >
      >  49c7c511000000 REX.W movq r13,<id>
      >  e8ea2f0700     call <entry>
      >
      > After:
      >
      >  41ff9560360000 call [r13+<entry offset>]
      >
      > Bug: v8:8661,v8:8768
      > Change-Id: I13e30aedc360474dc818fecc528ce87c3bfeed42
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465834
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70597}
      
      Tbr: ulan@chromium.org, tebbi@chromium.org, rmcilroy@chromium.org
      Bug: v8:8661,v8:8768,chromium:1140165
      Change-Id: Ibcd5c39c58a70bf2b2ac221aa375fc68d495e144
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485506Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70655}
      fbfa9bf4
    • Georg Neis's avatar
      [compiler] Check for stack overflow when unrolling JSBoundFunctions · 7eeac39f
      Georg Neis authored
      Gracefully handle hugely nested JSBoundFunctions by checking against
      the local isolate's stack limit in relevant recursive functions.
      
      This is based on d734bb4c (which was
      reverted).
      
      In order to get access to the local isolate, the CL replaces the heap
      broker's LocalHeap pointer with a LocalIsolate pointer.
      
      Bug: chromium:1125145
      Change-Id: I15d6265c7dfcd8a70af4ab4ce6f30149a886be00
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2480682
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70654}
      7eeac39f
    • Jakob Gruber's avatar
      Revert "[deoptimizer] Change deopt entries into builtins" · 8bc9a794
      Jakob Gruber authored
      This reverts commit 7f58ced7.
      
      Reason for revert: Segfaults on Atom_x64 https://ci.chromium.org/p/v8-internal/builders/ci/v8_linux64_atom_perf/5686?
      
      Original change's description:
      > [deoptimizer] Change deopt entries into builtins
      >
      > While the overall goal of this commit is to change deoptimization
      > entries into builtins, there are multiple related things happening:
      >
      > - Deoptimization entries, formerly stubs (i.e. Code objects generated
      >   at runtime, guaranteed to be immovable), have been converted into
      >   builtins. The major restriction is that we now need to preserve the
      >   kRootRegister, which was formerly used on most architectures to pass
      >   the deoptimization id. The solution differs based on platform.
      > - Renamed DEOPT_ENTRIES_OR_FOR_TESTING code kind to FOR_TESTING.
      > - Removed heap/ support for immovable Code generation.
      > - Removed the DeserializerData class (no longer needed).
      > - arm64: to preserve 4-byte deopt exits, introduced a new optimization
      >   in which the final jump to the deoptimization entry is generated
      >   once per Code object, and deopt exits can continue to emit a
      >   near-call.
      > - arm,ia32,x64: change to fixed-size deopt exits. This reduces exit
      >   sizes by 4/8, 5, and 5 bytes, respectively.
      >
      > On arm the deopt exit size is reduced from 12 (or 16) bytes to 8 bytes
      > by using the same strategy as on arm64 (recalc deopt id from return
      > address). Before:
      >
      >  e300a002       movw r10, <id>
      >  e59fc024       ldr ip, [pc, <entry offset>]
      >  e12fff3c       blx ip
      >
      > After:
      >
      >  e59acb35       ldr ip, [r10, <entry offset>]
      >  e12fff3c       blx ip
      >
      > On arm64 the deopt exit size remains 4 bytes (or 8 bytes in same cases
      > with CFI). Additionally, up to 4 builtin jumps are emitted per Code
      > object (max 32 bytes added overhead per Code object). Before:
      >
      >  9401cdae       bl <entry offset>
      >
      > After:
      >
      >  # eager deoptimization entry jump.
      >  f95b1f50       ldr x16, [x26, <eager entry offset>]
      >  d61f0200       br x16
      >  # lazy deoptimization entry jump.
      >  f95b2b50       ldr x16, [x26, <lazy entry offset>]
      >  d61f0200       br x16
      >  # the deopt exit.
      >  97fffffc       bl <eager deoptimization entry jump offset>
      >
      > On ia32 the deopt exit size is reduced from 10 to 5 bytes. Before:
      >
      >  bb00000000     mov ebx,<id>
      >  e825f5372b     call <entry>
      >
      > After:
      >
      >  e8ea2256ba     call <entry>
      >
      > On x64 the deopt exit size is reduced from 12 to 7 bytes. Before:
      >
      >  49c7c511000000 REX.W movq r13,<id>
      >  e8ea2f0700     call <entry>
      >
      > After:
      >
      >  41ff9560360000 call [r13+<entry offset>]
      >
      > Bug: v8:8661,v8:8768
      > Change-Id: I13e30aedc360474dc818fecc528ce87c3bfeed42
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465834
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70597}
      
      TBR=ulan@chromium.org,rmcilroy@chromium.org,jgruber@chromium.org,tebbi@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:8661,v8:8768,chromium:1140165
      Change-Id: I3df02ab42f6e02233d9f6fb80e8bb18f76870d91
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485504Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70649}
      8bc9a794
  27. 19 Oct, 2020 1 commit
    • Jakob Gruber's avatar
      [deoptimizer] Change deopt entries into builtins · 7f58ced7
      Jakob Gruber authored
      While the overall goal of this commit is to change deoptimization
      entries into builtins, there are multiple related things happening:
      
      - Deoptimization entries, formerly stubs (i.e. Code objects generated
        at runtime, guaranteed to be immovable), have been converted into
        builtins. The major restriction is that we now need to preserve the
        kRootRegister, which was formerly used on most architectures to pass
        the deoptimization id. The solution differs based on platform.
      - Renamed DEOPT_ENTRIES_OR_FOR_TESTING code kind to FOR_TESTING.
      - Removed heap/ support for immovable Code generation.
      - Removed the DeserializerData class (no longer needed).
      - arm64: to preserve 4-byte deopt exits, introduced a new optimization
        in which the final jump to the deoptimization entry is generated
        once per Code object, and deopt exits can continue to emit a
        near-call.
      - arm,ia32,x64: change to fixed-size deopt exits. This reduces exit
        sizes by 4/8, 5, and 5 bytes, respectively.
      
      On arm the deopt exit size is reduced from 12 (or 16) bytes to 8 bytes
      by using the same strategy as on arm64 (recalc deopt id from return
      address). Before:
      
       e300a002       movw r10, <id>
       e59fc024       ldr ip, [pc, <entry offset>]
       e12fff3c       blx ip
      
      After:
      
       e59acb35       ldr ip, [r10, <entry offset>]
       e12fff3c       blx ip
      
      On arm64 the deopt exit size remains 4 bytes (or 8 bytes in same cases
      with CFI). Additionally, up to 4 builtin jumps are emitted per Code
      object (max 32 bytes added overhead per Code object). Before:
      
       9401cdae       bl <entry offset>
      
      After:
      
       # eager deoptimization entry jump.
       f95b1f50       ldr x16, [x26, <eager entry offset>]
       d61f0200       br x16
       # lazy deoptimization entry jump.
       f95b2b50       ldr x16, [x26, <lazy entry offset>]
       d61f0200       br x16
       # the deopt exit.
       97fffffc       bl <eager deoptimization entry jump offset>
      
      On ia32 the deopt exit size is reduced from 10 to 5 bytes. Before:
      
       bb00000000     mov ebx,<id>
       e825f5372b     call <entry>
      
      After:
      
       e8ea2256ba     call <entry>
      
      On x64 the deopt exit size is reduced from 12 to 7 bytes. Before:
      
       49c7c511000000 REX.W movq r13,<id>
       e8ea2f0700     call <entry>
      
      After:
      
       41ff9560360000 call [r13+<entry offset>]
      
      Bug: v8:8661,v8:8768
      Change-Id: I13e30aedc360474dc818fecc528ce87c3bfeed42
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465834
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70597}
      7f58ced7
  28. 17 Oct, 2020 1 commit
  29. 16 Oct, 2020 1 commit
    • Dominik Inführ's avatar
      Reland "[compiler, heap] Create LocalHeap outside of ExecuteJob" · de914c75
      Dominik Inführ authored
      This is a reland of 44708a5b
      
      Original change's description:
      > [compiler, heap] Create LocalHeap outside of ExecuteJob
      >
      > Create LocalHeap directly in the Task or in GetOptimizedCodeNow and
      > pass its reference as argument to ExecuteJob. This allows us to create
      > LocalHeap differently for the main and background thread, e.g. by
      > passing an additional argument to the constructor in the future.
      > It will be required in the future anyways when the main thread will
      > have its own LocalHeap/LocalIsolate.
      >
      > Extending the scope of LocalHeap, also made
      > HandleBase::IsDereferenceAllowed more precise and uncovered two
      > potential issues: heap accesses in
      > OptimizingCompileDispatcher::CompileNext and PipelineImpl::AssembleCode
      > with --code-comments.
      >
      > LocalHeap can now be created in the parked state. Also fixed a data
      > race with LocalHeap's destructor publishing write barrier entries
      > without holding the lock.
      >
      > Bug: v8:10315
      > Change-Id: I9226972601a07b87108cd66efbbb6a0d118af58d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460818
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70521}
      
      Bug: v8:10315
      Change-Id: I4c459fd6dfb98d47fc9941c0dc6864bf5a1d2d3e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474788Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70560}
      de914c75
  30. 15 Oct, 2020 1 commit
    • Georg Neis's avatar
      Revert "[compiler, heap] Create LocalHeap outside of ExecuteJob" · 04c85d7c
      Georg Neis authored
      This reverts commit 44708a5b.
      
      Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/33692
      
      Original change's description:
      > [compiler, heap] Create LocalHeap outside of ExecuteJob
      >
      > Create LocalHeap directly in the Task or in GetOptimizedCodeNow and
      > pass its reference as argument to ExecuteJob. This allows us to create
      > LocalHeap differently for the main and background thread, e.g. by
      > passing an additional argument to the constructor in the future.
      > It will be required in the future anyways when the main thread will
      > have its own LocalHeap/LocalIsolate.
      >
      > Extending the scope of LocalHeap, also made
      > HandleBase::IsDereferenceAllowed more precise and uncovered two
      > potential issues: heap accesses in
      > OptimizingCompileDispatcher::CompileNext and PipelineImpl::AssembleCode
      > with --code-comments.
      >
      > LocalHeap can now be created in the parked state. Also fixed a data
      > race with LocalHeap's destructor publishing write barrier entries
      > without holding the lock.
      >
      > Bug: v8:10315
      > Change-Id: I9226972601a07b87108cd66efbbb6a0d118af58d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460818
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70521}
      
      TBR=ulan@chromium.org,neis@chromium.org,leszeks@chromium.org,solanes@chromium.org,dinfuehr@chromium.org
      
      Change-Id: I9dd1f8ca6237d5716b6d8938cef0ee3f642f3166
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10315
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474118Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70522}
      04c85d7c