- 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}
-
- 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}
-
- 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}
-
- 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 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}
-
- 17 Dec, 2020 2 commits
-
-
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}
-
- 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}
-
- 16 Oct, 2020 3 commits
-
-
Ross McIlroy authored
This is a reland of cdc8d9a5 Skipped tests on gc_stress and fixed CONSTEXPR_DCHECK for gcc. Original change's description: > [TurboProp] Avoid marking the output of a call live in its catch handler > > The output of a call won't be live if an exception is thrown while the > call is on the stack and we unwind to a catch handler. > > BUG=chromium:1138075,v8:9684 > > Change-Id: I95bf535bac388940869eb213e25565d64fe96df1 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2476317 > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70562} Bug: chromium:1138075 Bug: v8:9684 Change-Id: I685c94ee2ffcf06658df07fcef06f58c4f01f54b Cq-Include-Trybots: luci.v8.try:v8_linux64_gcc_compile_dbg Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2479009 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Auto-Submit: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#70573}
-
Michael Achenbach authored
This reverts commit cdc8d9a5. Reason for revert: The regression test is too slow: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/30454 Also gcc failures: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20gcc%20-%20debug/9528 Original change's description: > [TurboProp] Avoid marking the output of a call live in its catch handler > > The output of a call won't be live if an exception is thrown while the > call is on the stack and we unwind to a catch handler. > > BUG=chromium:1138075,v8:9684 > > Change-Id: I95bf535bac388940869eb213e25565d64fe96df1 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2476317 > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70562} TBR=rmcilroy@chromium.org,neis@chromium.org Change-Id: I0f6b9378d516a70401fc429fb3612bbf962b0fb2 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:1138075 Bug: v8:9684 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2479007Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#70564}
-
Ross McIlroy authored
The output of a call won't be live if an exception is thrown while the call is on the stack and we unwind to a catch handler. BUG=chromium:1138075,v8:9684 Change-Id: I95bf535bac388940869eb213e25565d64fe96df1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2476317 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#70562}
-
- 01 Sep, 2020 2 commits
-
-
Seth Brenith authored
This reverts commit 7f054679. Reason for revert: regressions on Emscripten/Fannkuch and JetStream/richards Original change's description: > [regalloc] Run SpillPlacer on any value defined in a loop > > I previously wrote a comment that said "We haven't seen any indication > of performance improvements from seeking optimal spilling positions > except on loop-top phi values". That statement is no longer true, now > that I've looked a little harder. In the latest version of the Mono > interpreter, we can improve performance by 2.5% by enabling SpillPlacer > for any value defined within a loop. > > Bug: v8:10606 > Change-Id: I25e06458c87ad4ffcefe52be3042032e05a47b35 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2381557 > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#69646} TBR=rmcilroy@chromium.org,seth.brenith@microsoft.com,thibaudm@chromium.org Change-Id: Ic3e74485f42bafedfe1890c0be32a29c3455afe5 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10606, chromium:1124028 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2388745Reviewed-by:
Seth Brenith <seth.brenith@microsoft.com> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#69658}
-
Seth Brenith authored
I previously wrote a comment that said "We haven't seen any indication of performance improvements from seeking optimal spilling positions except on loop-top phi values". That statement is no longer true, now that I've looked a little harder. In the latest version of the Mono interpreter, we can improve performance by 2.5% by enabling SpillPlacer for any value defined within a loop. Bug: v8:10606 Change-Id: I25e06458c87ad4ffcefe52be3042032e05a47b35 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2381557Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#69646}
-
- 18 Aug, 2020 1 commit
-
-
Ross McIlroy authored
MSVC on x86 has issues with ALIGNAS(8) on InstructionOperand, but does align the object to 8 bytes anyway. As a work-around, avoid ALIGNAS for InstructionOperand on MSVC x86. BUG=v8:10796 Change-Id: Iabb465489d97f9518a4429e8d78c06296539ed97 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2358680Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#69450}
-
- 29 Jul, 2020 2 commits
-
-
Daniel Clifford authored
Although the code generator already combines return instructions late in the pipeline into a common site, there were still superfluous jumps to that common site left in the code. Change-Id: I06c885fb0ab6a2c078f9dabdc6616c6881f42c75 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2284984 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#69133}
-
Victor Gomes authored
Change-Id: I41be2c5b0867739dbbe3667144bf6b479c609e53 Bug: chromium:1107221 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2322628 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Auto-Submit: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#69122}
-
- 28 Jul, 2020 1 commit
-
-
Ross McIlroy authored
Adds support for populating reference maps to the fast register allocator. In order to calculate whether a stack slot is live at a given instruction, we use the dominator tree to build a bitmap of blocks which are dominated by each block. A variable's spill operand is classed as alive for any blocks that are dominated by the block it was defined in, until the instruction index of the spill operand's last use. As such, it may be classified as live down a branch where the spill operand is never used, however it is safe since the spill slot won't be re-allocated until after it's last-use instruction index in any case. BUG=v8:9684 Change-Id: I772374599ef916f57d82d468f66429e32c712ddf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2298008 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#69108}
-
- 24 Jul, 2020 2 commits
-
-
Ross McIlroy authored
Adds support for register allocation within a block to the fast register allocator. Also adds some unittests covering basic register allocation. No support yet for spill slot allocation, so functions that spill don't work yet. BUG=v8:9684 Change-Id: I91d0fc0660d7b65f59235242fd5e3b1a7618d813 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2297467 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#69045}
-
Ross McIlroy authored
This is a reland of ab7e89f1 Original change's description: > [TurboProp] Add PendingOperand for use by fast register allocator. > > Adds a pending operand type for use with the fast register allocator. > These operands chain together multiple operands together, enabling > the allocator to keep track of multiple pending operands, then > replace them all with the allocated operand in one go. > > BUG=v8:9684 > > Change-Id: I5d8150f3f26549a747a2e89e32e31135e89dff9c > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2292302 > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69019} Bug: v8:9684 Change-Id: I60b902be82b766d98c0f08c9394fcac72d3b914a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2315994Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Auto-Submit: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#69042}
-
- 23 Jul, 2020 2 commits
-
-
Maya Lekova authored
This reverts commit ab7e89f1. Reason for revert: Breaks GCC build - https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20gcc%20-%20debug/8442? Original change's description: > [TurboProp] Add PendingOperand for use by fast register allocator. > > Adds a pending operand type for use with the fast register allocator. > These operands chain together multiple operands together, enabling > the allocator to keep track of multiple pending operands, then > replace them all with the allocated operand in one go. > > BUG=v8:9684 > > Change-Id: I5d8150f3f26549a747a2e89e32e31135e89dff9c > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2292302 > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69019} TBR=rmcilroy@chromium.org,tebbi@chromium.org Change-Id: If689956f873f05bcd920090143769a0d4686d804 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9684 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2315992Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#69023}
-
Ross McIlroy authored
Adds a pending operand type for use with the fast register allocator. These operands chain together multiple operands together, enabling the allocator to keep track of multiple pending operands, then replace them all with the allocated operand in one go. BUG=v8:9684 Change-Id: I5d8150f3f26549a747a2e89e32e31135e89dff9c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2292302 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#69019}
-
- 10 Jul, 2020 1 commit
-
-
Igor Sheludko authored
... by migrating old-style code MyObject* obj = new (zone) MyObject(...) to the new style MyObject* obj = zone->New<MyObject>(...) Bug: v8:10689 Change-Id: Iea6c1225ee672035763d8141292a40874658d270 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2288864 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#68788}
-
- 14 May, 2020 1 commit
-
-
Ng Zhi An authored
This only changes iterator type specifiers and cast expressions. See https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-auto.html for more on this warning. Bug: v8:10488 Change-Id: I1e6747aafb24fd2d9d946e054fb20fbd1d8e5b26 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2191921Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#67814}
-
- 17 Mar, 2020 1 commit
-
-
Georgia Kouveli authored
Generate a BTI instruction at each target of an indirect branch (BR/BLR). An indirect branch that doesn't jump to a BTI instruction will generate an exception on a BTI-enabled core. On cores that do not support the BTI extension, the BTI instruction is a NOP. Targets of indirect branch instructions include, among other things, function entrypoints, exception handlers and jump tables. Lazy deopt exits can potentially be reached through an indirect branch when an exception is thrown, so they also get an additional BTI instruction. Bug: v8:10026 Change-Id: I0ebf51071f1b604f60f524096e013dfd64fcd7ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967315 Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66751}
-
- 05 Mar, 2020 1 commit
-
-
Dan Elphick authored
Optimizes InstructionSelector::AddInputsToFrameStateDescriptor by taking advantage of SparseInputMask data structure to more quickly handle empty inputs and insert all the OptimizedOut entries in one go. The number of empty inputs is now determined using CountTrailingZeros rather than iterating over them one at a time. Gives a 9% improvement to SelectInstructions runtime call stat for Octane in turboprop. Bug: v8:10051 Change-Id: Ib13d6f9644b4c89ba0546a19fe0ed623d69fec99 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037443 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#66591}
-
- 13 Dec, 2019 2 commits
-
-
Dan Elphick authored
Moves the TailCall instruction codes to the start of the enum, and changes the test for IsTailCall from 4 equality tests to a single inequality. Bug: v8:10051 Change-Id: I679d6377161bd4f9a05f6202763d52c0a67b7900 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1964075Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#65440}
-
Michael Starzinger authored
R=clemensb@chromium.org Change-Id: Ibd6790a222590fd4dce9f918219a19f01c2e1e0f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1960293Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#65439}
-
- 15 Nov, 2019 1 commit
-
-
Dan Elphick authored
utils.h itself is fairly large and contains lots of unrelated functions as well as having a fair number of dependencies itself, so this splits bounds checking and bit field operations into their own headers in base and replaces uses of utils.h with the more appropriate header where possible. (Also fixes some cases where other headers were previously brought in transitively). Bug: v8:9810, v8:8912 Change-Id: I76c53f953848a57e2c5bfad6ce45abcd6d2a4f1b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1916604Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#64983}
-
- 11 Nov, 2019 1 commit
-
-
Santiago Aboy Solanes authored
Since smi-corrputing, TaggedSigned (aka known smis) only have the lower bits used. This renders CompressedSigned useless. Bug: v8:7703 Change-Id: Id59aaebc24d670ed32c483ceecf77fd194405ee4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1903445 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#64883}
-
- 31 Oct, 2019 1 commit
-
-
Michaël Zasso authored
This gets rid of a bunch of compiler warnings with MSVC. Change-Id: I73440f0d203603fe39a2408d2b9cc647700aa5fc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893334Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Michaël Zasso <mic.besace@gmail.com> Cr-Commit-Position: refs/heads/master@{#64692}
-
- 23 Oct, 2019 1 commit
-
-
Michael Starzinger authored
The {InstructionCode} is only used to store plain (non-negative) values of the {ArchOpcode} enum, or additionally encodes {BitField} values. The underlying base type 'U' of a {BitField} is uint32_t. To avoid all the numerous implicit conversions between int32_t and uint32_t, this is changing the {InstructionCode} so that uint32_t is used exclusively. R=neis@chromium.org BUG=v8:9872 Change-Id: If64107ad9298011e219b4827735eafb51465beb0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869193Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#64503}
-
- 17 Oct, 2019 1 commit
-
-
Milad Farazmand authored
The calling conventions on AIX uses function descriptors, which means that pointers to functions do not point to code, but instead point to metadata about them. When calling JITed code, we must assure to use function descriptors instead of raw pointers when needed. Before this CL 213504b9, all CallCFunction on AIX were guaranteed to have function descriptors. Starting form the CL mentioned above, CallCFunction can also Jump to a Trampoline which does not have a function descriptor, hence a new "CallCFunctionWithoutFunctionDescriptor" method is proposed to deal with this issue. BUG= v8:9766 Change-Id: I9343c31c812f5d4dda8503a5adf024b24dbde072 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1825961 Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#64357}
-
- 24 Sep, 2019 1 commit
-
-
Ng Zhi An authored
This gives nicer error messages. Was Fatal error in ../../src/compiler/backend/instruction.h, line 778 Debug check failed: i < InputCount(). Now Fatal error in ../../src/compiler/backend/instruction.h, line 778 Debug check failed: i < InputCount() (5 vs. 3). Bug: v8:9396 Change-Id: Iab2aea49245a42397bf07f4abf9e3de501c758b9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1817258Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#63954}
-
- 10 Sep, 2019 1 commit
-
-
Michael Starzinger authored
R=mvstanton@chromium.org BUG=v8:9396 Change-Id: Iaf1f6af19d3c4236c6f1c4b215b90b2e390e81d3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1789297 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Zhi An Ng <zhin@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#63631}
-
- 26 Aug, 2019 1 commit
-
-
Maya Lekova authored
This is a reland of 8ff8ddba Original change's description: > [turbofan] Further brokerize BytecodeGraphBuilder > > Replace all usages of VectorSlotPair with FeedbackSource. > > Bug: v8:7790 > Change-Id: I0ac6e9cd8f5730154cc1842e267ca1ebfdebc874 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763536 > Commit-Queue: Maya Lekova <mslekova@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63378} Bug: v8:7790 Change-Id: I54fbf4433a65681780fda4ded09ec2d145d36ec1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768361Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#63391}
-
- 23 Aug, 2019 2 commits
-
-
Bill Budge authored
This reverts commit 8ff8ddba. Reason for revert: Causes failures on GC Stress and TSan: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/24138 https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/27969 Original change's description: > [turbofan] Further brokerize BytecodeGraphBuilder > > Replace all usages of VectorSlotPair with FeedbackSource. > > Bug: v8:7790 > Change-Id: I0ac6e9cd8f5730154cc1842e267ca1ebfdebc874 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763536 > Commit-Queue: Maya Lekova <mslekova@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63378} TBR=neis@chromium.org,mslekova@chromium.org Change-Id: Ieb6fb24dd0626fd9eb2183844614ac5b3c8084e8 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7790 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1769287Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#63387}
-
Maya Lekova authored
Replace all usages of VectorSlotPair with FeedbackSource. Bug: v8:7790 Change-Id: I0ac6e9cd8f5730154cc1842e267ca1ebfdebc874 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763536 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63378}
-
- 22 Aug, 2019 3 commits
-
-
Jakob Gruber authored
This is a reland of 1e472c42 No change, this was a speculative revert to unblock the roll. TBR=jgruber Original change's description: > [compiler] Track the maximal unoptimized frame size > > This is another step towards considering the unoptimized frame size in > stack checks within optimized code. > > With the changes in this CL, we now keep track of the maximal > unoptimized frame size of the function that is currently being > compiled. An optimized function may inline multiple unoptimized > functions, so a single optimized frame can deopt to multiple > frames. The real frame size thus differs in different parts of the > optimized function. > > We only care about the maximal frame size, which we calculate > conservatively as an over-approximation, and track in > InstructionSelector::max_unoptimized_frame_height_ for now. In future > work, this value will be passed on to codegen, where it will be > applied as an offset to the stack pointer during the stack check. > > (The motivation behind this is to avoid stack overflows through deopts, > caused by size differences between optimized and unoptimized frames.) > > Note that this offset only ensure that the topmost optimized frame can > deopt without overflowing the stack limit. That's fine, because we only > deopt optimized frames one at a time. Other (non-topmost) frames are > only deoptimized once they are returned to. > > Drive-by: Print variable and total frame height in --trace-deopt. > > Bug: v8:9534 > Change-Id: I821684a9da93bff59c20c8ab226105e7e12d93eb > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762024 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Auto-Submit: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63330} Bug: v8:9534 Change-Id: I686f200e7be1f419e23e50789e11607a0b2886d9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1766645 Commit-Queue: Bill Budge <bbudge@chromium.org> Reviewed-by:
Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#63356}
-
Bill Budge authored
This reverts commit 1e472c42. Reason for revert: Speculative revert, to attempt to fix crashes that block the V8 roll. Example failure run: https://ci.chromium.org/p/chromium/builders/try/linux-rel/173465 Original change's description: > [compiler] Track the maximal unoptimized frame size > > This is another step towards considering the unoptimized frame size in > stack checks within optimized code. > > With the changes in this CL, we now keep track of the maximal > unoptimized frame size of the function that is currently being > compiled. An optimized function may inline multiple unoptimized > functions, so a single optimized frame can deopt to multiple > frames. The real frame size thus differs in different parts of the > optimized function. > > We only care about the maximal frame size, which we calculate > conservatively as an over-approximation, and track in > InstructionSelector::max_unoptimized_frame_height_ for now. In future > work, this value will be passed on to codegen, where it will be > applied as an offset to the stack pointer during the stack check. > > (The motivation behind this is to avoid stack overflows through deopts, > caused by size differences between optimized and unoptimized frames.) > > Note that this offset only ensure that the topmost optimized frame can > deopt without overflowing the stack limit. That's fine, because we only > deopt optimized frames one at a time. Other (non-topmost) frames are > only deoptimized once they are returned to. > > Drive-by: Print variable and total frame height in --trace-deopt. > > Bug: v8:9534 > Change-Id: I821684a9da93bff59c20c8ab226105e7e12d93eb > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762024 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Auto-Submit: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63330} TBR=neis@chromium.org,sigurds@chromium.org,jgruber@chromium.org Change-Id: I7b225c30bfc4e1d958276583f512a1ec5fa2b458 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9534 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1764626Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#63350}
-
Jakob Gruber authored
This is another step towards considering the unoptimized frame size in stack checks within optimized code. With the changes in this CL, we now keep track of the maximal unoptimized frame size of the function that is currently being compiled. An optimized function may inline multiple unoptimized functions, so a single optimized frame can deopt to multiple frames. The real frame size thus differs in different parts of the optimized function. We only care about the maximal frame size, which we calculate conservatively as an over-approximation, and track in InstructionSelector::max_unoptimized_frame_height_ for now. In future work, this value will be passed on to codegen, where it will be applied as an offset to the stack pointer during the stack check. (The motivation behind this is to avoid stack overflows through deopts, caused by size differences between optimized and unoptimized frames.) Note that this offset only ensure that the topmost optimized frame can deopt without overflowing the stack limit. That's fine, because we only deopt optimized frames one at a time. Other (non-topmost) frames are only deoptimized once they are returned to. Drive-by: Print variable and total frame height in --trace-deopt. Bug: v8:9534 Change-Id: I821684a9da93bff59c20c8ab226105e7e12d93eb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762024 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63330}
-