- 09 Jun, 2022 1 commit
-
-
Georgia Kouveli authored
The allowlist used for `Deoptimizer::IsValidReturnAddress` depends on fixed embedded builtin addresses. Pass a pointer to the isolate to this method, so that it can discover the actual builtin code start (which may have been remapped) and calculate the offset from the start of the builtins' code in order to check if the return address is allowed. After this change, do not disable short builtin calls when CFI is enabled. There's an important TODO for this change: Since the builtin code pointer that's used to check whether a return address is allowed is now writable, we should use pointer authentication to protect it. Bug: v8:10026 Change-Id: Iafd31d3ad7e10cb17faf33e76e78d3df36edeefd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3667506Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com> Cr-Commit-Position: refs/heads/main@{#81049}
-
- 11 May, 2022 1 commit
-
-
Simon Zünd authored
Doc: https://bit.ly/revive-restart-frame This CL implements support for the Debugger's "restart frame" functionality in the deoptimizer. When the debugger wants to restart a frame, we throw a termination exception. If the restarted frame is an optimized frame or was inlined into an optimized frame, the deoptimizer has to materialize all the frames up to (and including) the frame we want to restart. This is similar to materializing all the frames up until the frame with a catch handler. The main difference is that we do not jump into the middle of the top-most materialized frame, but instead use the RestartFrameTrampolone to immediatly exit, and then re-invoke the top-most materialized frame. R=jarin@chromium.org, tebbi@chromium.org Bug: chromium:1303521 Change-Id: I74ee412bc67f027be81fe56e529b5e5161e97153 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616504Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/main@{#80462}
-
- 28 Apr, 2022 1 commit
-
-
Victor Gomes authored
... from ArgumentsAdaptorFrame to InlinedExtraArguments. Change-Id: I772e0546dd50282a4cd14723625fd5bf774f424c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3609968Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/main@{#80250}
-
- 27 Apr, 2022 1 commit
-
-
Jakob Gruber authored
This logic was confused in the presence of inlined frames; the deopt exit offset would point inside the innermost inlined frame while we incorrectly assumed it points at the outermost frame. Fix this by always referring to the bytecode offset of the outermost frame. Bug: v8:12161 Fixed: chromium:1320094 Change-Id: I2eb28498639432c5344859f64a9388d93ee23bde Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3608630 Auto-Submit: Jakob Linke <jgruber@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#80212}
-
- 26 Apr, 2022 1 commit
-
-
Jakob Gruber authored
.. when deoptimization occurs after the outermost loop containing the loop that triggered OSR compilation. The reasoning is that the main benefit of OSR'd code is speeding up the OSR'd loop; the speedup of the OSR'd loop is assumed to be higher than deoptimization overhead. This is a slightly modified version of crrev.com/c/3521361, credit goes to tao.pan@intel.com for most of the investigation and implementation work. Bug: v8:12161 Change-Id: Ie729dd5d1df9c7f529a1cf1b9471bb60ce76c41a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3607988Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#80177}
-
- 04 Apr, 2022 1 commit
-
-
Jakob Gruber authored
.. since they are the same as eager deopts (% an unused counter). Fixed: v8:12765 Change-Id: I2be6210e476ead4ac6629a49259f28321e965867 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3565717Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79729}
-
- 29 Mar, 2022 1 commit
-
-
Leszek Swirski authored
All architectures have kSupportsFixedDeoptExitSizes = true, so we can remove kSupportsFixedDeoptExitSizes entirely and always have fixed-size deopts. Change-Id: Ib696f6d2431f60677cc7fa2193ee27b9b0f80bc8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3550268Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#79654}
-
- 24 Mar, 2022 1 commit
-
-
Jakob Gruber authored
This reverts part of crrev.com/c/2413252 since std::unique_ptr does not satisfy is_standard_layout; and is_standard_layout is needed to use offsetof: error: offset of on non-standard-layout type [-Werror,-Winvalid-offsetof] Fixed: v8:12721 Change-Id: Ifbb1235fc3b8d1d855d41a226117fed88c506078 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3540141Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79597}
-
- 21 Mar, 2022 1 commit
-
-
Jakob Gruber authored
This CL removes: - Dynamic map checks aka minimorphic property loads (TF support, builtins). - "Bailout" deopts (= drop to the interpreter once, but don't throw out optimized code). - "EagerWithResume" deopts (= part of dynamic map check functionality, we call a builtin for the deopt check and deopt or resume based on the result). Fixed: v8:12552 Change-Id: I492cf1667e0f54586690b2f72a65ea804224b840 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3401585 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#79544}
-
- 10 Mar, 2022 1 commit
-
-
Jakob Gruber authored
This reverts commit 190b5d95. Reason for revert: We should understand & fix regressions, see crbug.com/1304870#c9. Original change's description: > [compiler] Don't remove OSR code cache if deoptimizing at out of loop > > The main purpose of OSR compilation is fasten inner loop execution, the > OSR code cache is still correct for loop if optimizing at out of loop, > keep OSR code cache can reduce unnecessary slow bytecode execution with > feedback collection and avoid re-OSR compilation. > This CL can improve JetStream2 case navier-stokes by ~6%. > > Change-Id: I9518317fb922071b131cab5b56998a0fc198804a > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3494981 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Tao Pan <tao.pan@intel.com> > Cr-Commit-Position: refs/heads/main@{#79413} Bug: chromium:1304870 Change-Id: I8791edc34b66ef9dd0b477d3e340e85b0617ef59 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3515732 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79435}
-
- 09 Mar, 2022 1 commit
-
-
Pan, Tao authored
The main purpose of OSR compilation is fasten inner loop execution, the OSR code cache is still correct for loop if optimizing at out of loop, keep OSR code cache can reduce unnecessary slow bytecode execution with feedback collection and avoid re-OSR compilation. This CL can improve JetStream2 case navier-stokes by ~6%. Change-Id: I9518317fb922071b131cab5b56998a0fc198804a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3494981Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Tao Pan <tao.pan@intel.com> Cr-Commit-Position: refs/heads/main@{#79413}
-
- 20 Jan, 2022 1 commit
-
-
Jakob Gruber authored
Bug: v8:12552 Change-Id: I99e4d8e8aeba5460f11e54cc1b2bcaea98a5276d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3400964Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#78698}
-
- 11 Aug, 2021 1 commit
-
-
Nico Hartmann authored
When running d8 with --trace-deopt, any deopt will contain the id of the node that caused this deopt. These ids also show up in the deoptimization data table of when using --print-opt-code. Change-Id: I412ca7a4ff20427100fa63101d78ee3846569a8e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3024144Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#76220}
-
- 07 Jun, 2021 1 commit
-
-
Camillo Bruni authored
- Add new Builtin enum - Move Builtins::Name:kXXX to Builtin::kXXX - Update existing code Follow CLs will unify the mix of using int builtin-ids and Builtins::Name to only use the new Builtin enum and changing it to an enum class. Change-Id: Ib39aa45a25696acdf147f46392901b1e051deaa4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2905592 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#74995}
-
- 08 Mar, 2021 1 commit
-
-
Clemens Backes authored
This removes all includes of src/wasm from src/deoptimizer, by #if'ing out wasm-related parts. This will allow to later exclude the whole src/wasm directory from compilation. Drive-by: Inline DecodeWasmReturnKind and EncodeWasmReturnKind to avoid more #ifs. R=jgruber@chromium.org Bug: v8:11238 Change-Id: Ia49ed26fc217b3e80756a363dcd397d9060f6835 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2739653Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73261}
-
- 26 Feb, 2021 1 commit
-
-
Clemens Backes authored
This renames more fields holding "ValueKind" or methods operating on "ValueKind" to contain "kind" instead of "type". It also renames "is_reference_type" to "is_reference" on both ValueType and ValueKind, as the "_type" prefix is kind of implicit from the argument. R=manoskouk@chromium.org, jgruber@chromium.org Bug: v8:11477 Change-Id: I7809f1af6e983aebca96e03fe1fbc6ccaa22db72 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718063 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#73070}
-
- 22 Feb, 2021 1 commit
-
-
Clemens Backes authored
Backends do not care about the concrete type, they only need to know the "kind" (e.g. "ref" or "i32"). In order to prepare Liftoff to use the value kind instead of the value type for all stored data, this CL moves the kind out of the ValueType and makes it a top-level enum. R=manoskouk@chromium.org Bug: v8:11477 Change-Id: I489d6c5207e6ff1b66e2afbe78a156d66df27eb3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2707169 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#72896}
-
- 15 Feb, 2021 2 commits
-
-
Leszek Swirski authored
Add a new StackFrame class for unoptimized frames (which are either interpreted or baseline). BaselineFrame becomes a subclass of this rather than InterpretedFrame, and the various frame constants helpers are similarly amended. Bug: v8:11420, v8:11429 Change-Id: I87e9368aef48ef06a39476bf826f379ce1441528 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692208 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#72743}
-
Victor Gomes authored
- Baseline is to be consider non-optimized code, so for consistency we rename these functions to DiscardBaselineCode. - Move to debug/, since discarding baseline code is only used by the debugger. - %DeoptimizeNow and %DeoptimizeFunction are not to be used to tier down from Sparkplug to Ignition Change-Id: I050607d4d6978907c589e54c57e940979b0a9a15 Bug: v8:11429 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692699Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#72732}
-
- 12 Feb, 2021 2 commits
-
-
Leszek Swirski authored
Currently we sometimes refer to baseline code or the baseline compiler by its codename (Sparkplug). The codename is fun, but we should be consistent and call things by one name or the other. Following the pattern of Ignition stuff being called "interpreter", we call Sparkplug "baseline", and leave the codename only in flags and variants. Bug: v8:11420 Change-Id: I432e5629518be7c7ad38b6acff024c91d4cfd6d3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692186 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#72696}
-
Leszek Swirski authored
Sparkplug is a new baseline, non-optimising second-tier compiler, designed to fit in the compiler trade-off space between Ignition and TurboProp/TurboFan. Design doc: https://docs.google.com/document/d/13c-xXmFOMcpUQNqo66XWQt3u46TsBjXrHrh4c045l-A/edit?usp=sharing Bug: v8:11420 Change-Id: Ideb7270db3d6548eedd8337a3f596eb6f8fea6b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2667514 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/master@{#72686}
-
- 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}
-
- 25 Jan, 2021 1 commit
-
-
Jakob Gruber authored
The final CL of this chain, this extracts translation opcodes into the TranslationOpcode class, and merges logic for TranslationArray creation into TranslationArrayBuilder. Drive-by: Pull TranslationArray printing logic into translation-state.cc. Bug: v8:11332 Change-Id: Ia4bbb6cdd15ea3318dfb9b7edb6eb881530dda54 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2642254 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#72278}
-
- 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 2 commits
-
-
Jakob Gruber authored
deoptimized-frame-info: Used only by the debugger. translated-state: Combines translations and current frame states to describe in- and output frames. translation-array: Utils for accessing the on-heap TranslationArray object. Bug: v8:11332 Change-Id: I86757bed370d6d9e493862eb24a9e92533f80933 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2640414 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#72229}
-
Jakob Gruber authored
This CL keep the Deoptimizer class in deoptimizer.{h,cc} and moves everything else into translations.{h,cc}. Translations may be further split up in follow-up work. Drive-by: Remove dead code and clean up includes. Bug: v8:11332 Change-Id: If774399843da1322c01e03d71c97b10fc88e45cb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639955Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#72228}
-
- 20 Jan, 2021 2 commits
-
-
Jakob Gruber authored
The bytecode offset (previously 'bailout id') was referred to as 'ast id', 'node id', 'bailout id' in different spots. And 'bailout id' was used to refer to deoptimization exits. This CL makes used terms more consistent. Bug: v8:11332 Change-Id: I2b34c7d4ebf465939e18fdfba675d83852f2430a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639756 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#72190}
-
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 1 commit
-
-
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}
-
- 18 Jan, 2021 1 commit
-
-
Victor Gomes authored
Removes: - v8_disable_arguments_adaptor GN flag - ArgumentsAdaptorTrampoline - ArgumentsAdaptorFrame class Change-Id: I382ebe6c25c3c172bee5df3e86e762fca10fa392 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2622911Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#72133}
-
- 17 Dec, 2020 3 commits
-
-
Nico Hartmann authored
This CL changes SharedFunctionInfo::GetBytecodeArray to a function template, which is specialized for Isolate and LocalIsolate arguments. This allows main thread only uses to avoid taking a lock. Bug: v8:7790, chromium:1154603 Change-Id: I3462c4e36b66073e09393c01c765dd8a018a98f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595307 Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#71833}
-
Nico Hartmann authored
This reverts commit 860fcb1b. Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm%20-%20sim%20-%20lite/13831/overview Original change's description: > Faster JS-to-Wasm calls > > This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/. > > Currently JS-to-Wasm calls go through a wrapper/trampoline, built on > the basis of the signature of a Wasm function to call, and whose task > is to: > - set "thread_in_wasm_flag" to true > - convert the arguments from tagged types into Wasm native types > - calculate the address of the Wasm function to call and call it > - convert back the result from Wasm native types into tagged types > - reset "thread_in_wasm_flag" to false. > > This CL tries to improve the performance of JS-to-Wasm calls by > inlining the code of the JS-to-Wasm wrappers in the call site. > > It introduces a new IR operand, JSWasmCall, which replaces JSCall for > this kind of calls. A 'JSWasmCall' node is associated to > WasmCallParameters, which contain information about the signature of > the Wasm function to call. > > WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid generating code to convert the types for the arguments > of the Wasm function, when the conversion is not necessary. > The actual inlining of the graph generated for this wrapper happens in > the simplified-lowering phase. > > A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage > lazy deoptimizations that can happen if the Wasm function callee calls > back some JS code that invalidates the compiled JS caller function. > > Bug: v8:11092 > Change-Id: I3174c1c1f59b39107b333d1929ecc0584486b8ad > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557538 > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Georg Neis (ooo until January 5) <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Commit-Queue: Paolo Severini <paolosev@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#71824} TBR=neis@chromium.org,ahaas@chromium.org,jgruber@chromium.org,tebbi@chromium.org,ishell@chromium.org,mslekova@chromium.org,nicohartmann@chromium.org,paolosev@microsoft.com Change-Id: I214cbdee74c1a2aaad907ffc84662ed25631983e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:11092 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595438Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#71825}
-
Paolo Severini authored
This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/. Currently JS-to-Wasm calls go through a wrapper/trampoline, built on the basis of the signature of a Wasm function to call, and whose task is to: - set "thread_in_wasm_flag" to true - convert the arguments from tagged types into Wasm native types - calculate the address of the Wasm function to call and call it - convert back the result from Wasm native types into tagged types - reset "thread_in_wasm_flag" to false. This CL tries to improve the performance of JS-to-Wasm calls by inlining the code of the JS-to-Wasm wrappers in the call site. It introduces a new IR operand, JSWasmCall, which replaces JSCall for this kind of calls. A 'JSWasmCall' node is associated to WasmCallParameters, which contain information about the signature of the Wasm function to call. WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid generating code to convert the types for the arguments of the Wasm function, when the conversion is not necessary. The actual inlining of the graph generated for this wrapper happens in the simplified-lowering phase. A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage lazy deoptimizations that can happen if the Wasm function callee calls back some JS code that invalidates the compiled JS caller function. Bug: v8:11092 Change-Id: I3174c1c1f59b39107b333d1929ecc0584486b8ad Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557538Reviewed-by:
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}
-
- 16 Dec, 2020 3 commits
-
-
Ross McIlroy authored
This is a reland of b2a611d8 Original change's description: > [Turboprop] Move dynamic check maps immediate args to deopt exit. > > Rather than loading the immediate arguments required by the > dynamic check maps builtin into registers in the fast-path, > instead insert them into the instruction stream in the deopt > exit and have the builtin load them into registers itself. > > BUG=v8:10582 > > Change-Id: I66716570b408501374eed8f5e6432df64c6deb7c > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2589736 > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#71790} TBR=tebbi@chromium.org,gsathya@chromium.org Bug: v8:10582 Change-Id: Ieda0295ee135bff983c67c3f04bb47115f0a2739 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595311Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#71803}
-
Clemens Backes authored
This reverts commit b2a611d8. Reason for revert: Several failures on https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20CFI/3743/overview Original change's description: > [Turboprop] Move dynamic check maps immediate args to deopt exit. > > Rather than loading the immediate arguments required by the > dynamic check maps builtin into registers in the fast-path, > instead insert them into the instruction stream in the deopt > exit and have the builtin load them into registers itself. > > BUG=v8:10582 > > Change-Id: I66716570b408501374eed8f5e6432df64c6deb7c > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2589736 > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#71790} TBR=rmcilroy@chromium.org,gsathya@chromium.org,tebbi@chromium.org Change-Id: I4c56bee156ffcea8de0aeaff9ac1bf03e03134c9 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10582 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595308Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#71793}
-
Ross McIlroy authored
Rather than loading the immediate arguments required by the dynamic check maps builtin into registers in the fast-path, instead insert them into the instruction stream in the deopt exit and have the builtin load them into registers itself. BUG=v8:10582 Change-Id: I66716570b408501374eed8f5e6432df64c6deb7c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2589736 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#71790}
-
- 01 Dec, 2020 1 commit
-
-
Ross McIlroy authored
In order to reduce the codegen size of dynamic map checks, add the ability to have an eager with resume deopt point, which can call a given builitin to perform a more detailed check than can be done in codegen, and then either deoptimizes itself (as if the calling code had performed an eager deopt) or resumes execution in the calling code after the check. In addition, support for adding extra arguments to a deoptimization continuation is added to enable us to pass the necessary arguments to the DynamicMapChecks builtin. Finally, a trampoline is added to the DynamicMapChecks which saves the registers that might be clobbered by that builtin, to avoid having to save them in the generated code. This trampoline also performs the deoptimization based on the result of the DynamicMapChecks builtin. In order to ensure both the trampoline and DynamicMapChecks builtin have the same call interface, and to limit the number of registers that need saving in the trampoline, the DynamicMapChecks builtin is moved to be a CSA builtin with a custom CallInterfaceDescriptor, that calls an exported Torque macro that implements the actual functionality. All told, this changes the codegen for a monomorphic dynamic map check from: movl rbx,<expected_map> cmpl [<object>-0x1],rbx jnz <deferred_call> resume_point: ... deferred_call: <spill registers> movl rax,<slot> movq rbx,<object> movq rcx,<handler> movq r10,<DynamicMapChecks> call r10 cmpq rax,0x0 jz <restore_regs> cmpq rax,0x1 jz <deopt_point_1> cmpq rax,0x2 jz <deopt_point_2> int3l restore_regs: <restore_regs> jmp <resume_point> ... deopt_point_1: call Deoptimization_Eager deopt_point_2: call Deoptimization_Bailout To: movl rax,<slot> movl rcx,<expected_map> movq rdx,<handler> cmpl [<object>-0x1],rcx jnz <deopt_point> resume_point: ... deopt_point: call DynamicMapChecksTrampoline jmp <resume_point> BUG=v8:10582 Change-Id: Ica4927b9acc963b9b73dc62d9379a7815335650f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2560197 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#71545}
-
- 20 Nov, 2020 1 commit
-
-
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}
-
- 17 Nov, 2020 1 commit
-
-
John Xu authored
Bug: v8:10927 Change-Id: Icbdc0d7329ddd466e7d67a954246a35795b4dece Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2507310 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#71220}
-
- 10 Nov, 2020 1 commit
-
-
Victor Gomes authored
- It also fixes padding issues in the deoptimizer Change-Id: Icac62892657830d067b7c21ff45b43ba58e350d9 Bug: v8:10201 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2498694 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#71090}
-