- 12 Feb, 2021 2 commits
-
-
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: Santiago Aboy Solanes <solanes@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#72722}
-
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: Georg Neis <neis@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Stanton <mvstanton@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@{#72697}
-
- 10 Feb, 2021 1 commit
-
-
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: Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#72619}
-
- 09 Feb, 2021 1 commit
-
-
Georg Neis authored
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/+/2661462Reviewed-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}
-
- 05 Feb, 2021 1 commit
-
-
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: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#72541}
-
- 26 Jan, 2021 1 commit
-
-
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: Georg Neis <neis@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#72331}
-
- 22 Jan, 2021 1 commit
-
-
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: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#72253}
-
- 21 Jan, 2021 1 commit
-
-
Jakob Gruber authored
OWNERS files: removed tebbi's entry. TODOs: replaced with 'turbofan'. Change-Id: Ib7a90418b394f123b82051379f120f0323d04097 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639757Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Hablich <hablich@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#72223}
-
- 20 Jan, 2021 1 commit
-
-
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: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72189}
-
- 19 Jan, 2021 2 commits
-
-
Santiago Aboy Solanes authored
Bug: v8:7790 Change-Id: I7900d041ff1331991d14e2766a6760b69f37622e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637230Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#72172}
-
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: 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}
-
- 14 Jan, 2021 1 commit
-
-
Manos Koukoutos authored
Changes: - Add --wasm-loop-unrolling flag. Everything in this CL happens behind this flag. - In decoding, DoReturn does not take returned values as an argument. It is now the responsibility of graph-builder-interface.cc to extract these values. Note that this is what was already happening in Liftoff. - In pipeline.cc, add phase to remove loop exits after generating the turbofan graph. - Explicitly disallow calling FallThruTo() on loops. - Add loop assignments and loop header node to Control type in graph-builder-interface.cc. Assign them in Loop(). - Main change: Add loop exit nodes to wasm-generated graphs. For details, consult this design doc: https://docs.google.com/document/d/1AsUCqslMUB6fLdnGq0ZoPk2kn50jIJAWAL77lKXXP5g - Inline PrepareForLoop(). Bug: v8:11298 Change-Id: I65058f1b5df3f862f4a62f4dcb0bd7e1f1dcf4ee Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2621082 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#72094}
-
- 17 Dec, 2020 1 commit
-
-
Andreas Haas authored
The TurboFan events, like time in register allocation, are only interesting in special cases, but create lots of events. Therefore it is good to put these events into their own tracing category. Bug: chromium:1084929 Change-Id: I971badc1ff58f99bd57b2ddfc93b625b356d6a2d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595436Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#71830}
-
- 15 Dec, 2020 1 commit
-
-
Dominik Inführ authored
When dereferencing handles check whether the main thread is parked similar to background threads. Bug: chromium:1152995 Change-Id: Ic79680f1b1c49f5f0ad872d6377ca45920a18b98 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2575061Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Georg Neis (ooo until January 5) <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#71760}
-
- 26 Nov, 2020 1 commit
-
-
Santiago Aboy Solanes authored
Scopes in V8 are used to guarantee one or more properties during its lifetimes. If a scope is not named e.g MyClassScope(args) instead of MyClassScope scope(args) it will get created and automatically destroyed and therefore, being useless as a scope. This CL would produce a compiling warning when that happens to ward off this developer error. Follow-up to ccrev.com/2552415 in which it was introduced and implemented for Guard classes. Change-Id: Ifa0fb89cc3d9bdcdee0fd8150a2618af5ef45cbf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2555001 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#71425}
-
- 25 Nov, 2020 1 commit
-
-
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: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#71405}
-
- 20 Nov, 2020 2 commits
-
-
Leszek Swirski authored
Because of LocalHeap safepoints, our existing assert scopes don't necessarily maintain the same guarantees as desired. In particular, DisallowHeapAllocation no longer guarantees that objects don't move. This patch transitions DisallowHeapAllocation to DisallowGarbageCollection, to ensure that code using this scope is also protected against safepoints. Change-Id: I0411425884f6849982611205fb17bb072881c722 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2540547 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#71319}
-
Clemens Backes authored
We had a test which first enabled the profiler, and then compiled wasm code. In this case, all code objects were registered correctly and the profile looked as expected. This CL extends the test for also test another order: First compile the wasm code, then enable the profiler. In that case, we were reporting a wrong debug name of the exported wasm function. The name of that function is spec'ed to be the string representation of the function index. But for debugging, we want to see a more meaningful name, identical to the name we show when reporting the code during compilation. This fix requires handlifying the {SharedFunctionInfo::DebugName} method, because for exported wasm functions, it needs to allocate a new name on the JS heap. In order to avoid this allocation where possible, a second variant is added which returns a unique_ptr directly. This can be used in all places where the name is just being printed, which turned out to be the majority of cases ({DebugName().ToCString()}). R=petermarshall@chromium.org Bug: chromium:1141787 Change-Id: I0343c2f06f0b852007535ff07459b712801ead01 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2543931 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#71308}
-
- 19 Nov, 2020 1 commit
-
-
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: Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#71274}
-
- 17 Nov, 2020 2 commits
-
-
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: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#71228}
-
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: 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}
-
- 13 Nov, 2020 1 commit
-
-
Nico Hartmann authored
This is the 2nd step in series of CLs to move the SharedFunctionInfo class to kNeverSerialized and make it concurrently accessible from the background thread. This CL: * Changes optimization of GetTemplateObject in JSCreateLowering to only perform the optimization of a template object exists in the SharedFunctionInfo[Ref], but skips the optimization if one is missing instead of allocating a new one on demand. Bug: v8:7790 Change-Id: Ic37d8333676e54b3f8d69416480df12bd90723ea Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2463229 Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#71189}
-
- 06 Nov, 2020 1 commit
-
-
Nico Hartmann authored
Bug: v8:11074 Change-Id: I6d58d523254915a6b0d6542d8f80ddc6cee71dee Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2520907Reviewed-by: Zhi An Ng <zhin@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#71003}
-
- 03 Nov, 2020 1 commit
-
-
Mythri A authored
Turboprop adds a negative implication for inlining to disable inlining with turboprop. When we add tiering up support from Turboprop, this implication means we would no longer inline functions even with Turbofan. This cl instead turns off inlining for turboprop compilations so we still don't inline for Turboprop compilations but support inlining for Turbofan. Bug: v8:9684 Change-Id: I5c7d2ca02f591ea007d66725200f12a4b0025d85 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2517119 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#70951}
-
- 02 Nov, 2020 1 commit
-
-
Mythri A authored
This cl adds support for tiering up in TurboProp. This cl makes necessary changes to support tier up but doesn't tier up yet. More specifically this cl: 1. Introduces a new flag for interrupt_budget_for_midtier and updates code to use the correct interrupt_budget. 2. Introduces a flag turboprop_as_midtier and necessary support to tier up. When this flag is enabled, we introduce checks for tierup and updating interrupt budget. Bug: v8:9684 Change-Id: I58785ce4b9de46488a22d3b4d0cebedac460a773 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460822 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@{#70915}
-
- 29 Oct, 2020 1 commit
-
-
Santiago Aboy Solanes authored
Inside of LoopPeeler::PeelInnerLoopsOfTree we call the typer, which inspects heap objects, so we need to unpark the local heap. Reverted in https://chromium-review.googlesource.com/c/v8/v8/+/2502333 Original change's description: > [compiler] Replace Symbol with direct reads > > Bug: v8:7790 > Change-Id: I49120a6349777fd992a97d697940e79b2e71dbd1 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2400988 > Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69812} Bug: v8:7790, chromium:1137594 Change-Id: I8539175002e19b04b84009eb6b2cc5ced4ee53c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2502339 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#70872}
-
- 28 Oct, 2020 2 commits
-
-
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: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#70856}
-
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: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#70834}
-
- 27 Oct, 2020 3 commits
-
-
Mythri Alle authored
This reverts commit d7ece57e. Reason for revert: failures on NumFuzz https://ci.chromium.org/p/v8/builders/ci/V8%20NumFuzz%20-%20debug/11818? 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} TBR=rmcilroy@chromium.org,mythria@chromium.org,jgruber@chromium.org Change-Id: Ia9894fef713a522b9c3d349bef4abcde3e1e1832 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9684 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2502870Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#70803}
-
Shu-yu Guo authored
Change-Id: I7c288f4e0c1dbc9600be2ccd69faecc4d38de17e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2500413Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#70802}
-
Mythri A authored
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}
-
- 21 Oct, 2020 1 commit
-
-
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: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#70672}
-
- 20 Oct, 2020 4 commits
-
-
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: Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#70658}
-
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: 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}
-
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: Maya Lekova <mslekova@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#70654}
-
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: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#70649}
-
- 19 Oct, 2020 1 commit
-
-
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: 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}
-
- 17 Oct, 2020 1 commit
-
-
Dominik Inführ authored
LocalHeap can be used on main thread, however allocation might cause a GC which works differently on the main thread than on a background thread. Support collection on main thread by directly performing the GC instead of requesting the GC as done on background threads. To allow for differentiation between main and background threads, LocalHeap/LocalIsolate now require an additional argument. Change-Id: I08094ea633e303e149913f21dff395da9e046534 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2463238Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#70590}
-
- 16 Oct, 2020 1 commit
-
-
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: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#70560}
-
- 15 Oct, 2020 1 commit
-
-
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: Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#70522}
-