- 26 Jul, 2022 1 commit
-
-
Hao Xu authored
pt.1 Compiler generates the below instructions for compressed pointer: [ DecompressTaggedPointer movl r8,[r8+0x13] REX.W addq r8,r14 ] addl [r8+0x7],0xe6 This CL optimizes the pointer decompression by using complex addressing mode in x64: movl r8,[r8+0x13] addl [r14+r8*1+0x7],0xe6 Bug: v8:13056, v8:7703 Change-Id: I755cdac407bab4ff2e78d4a6a164f13385f7c361 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3765067Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Hao A Xu <hao.a.xu@intel.com> Cr-Commit-Position: refs/heads/main@{#81967}
-
- 19 Jul, 2022 1 commit
-
-
Pierre Langlois authored
We already generate BTI instructions with `BaselineAssembler::JumpTarget()` on `VisitSingleBytecode()`, so we shouldn't need to do it when binding a label. Bug: v8:13082 Change-Id: Ie4d645a2379c3feb4909be524b42ebd85a8d35af Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3771861Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Pierre Langlois <pierre.langlois@arm.com> Cr-Commit-Position: refs/heads/main@{#81813}
-
- 13 May, 2022 1 commit
-
-
Clemens Backes authored
Now that we require C++17 support, we can just use the standard static_assert without message, instead of our STATIC_ASSERT macro. R=leszeks@chromium.org Bug: v8:12425 Change-Id: I1d4e39c310b533bcd3a4af33d027827e6c083afe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3647353Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#80524}
-
- 02 May, 2022 1 commit
-
-
Jakob Linke authored
This is a reland of commit 91453880 Fixed: properly reference the ClearedValue in CSA (i.e. without the cage_base upper 32 bits). Original change's description: > Reland "[osr] Use the new OSR cache" > > This is a reland of commit 91da3883 > > Fixed: Use an X register for JumpIfCodeTIsMarkedForDeoptimization > on arm64. > > Original change's description: > > [osr] Use the new OSR cache > > > > This CL switches over our OSR system to be based on the feedback > > vector osr caches. > > > > - OSRing to Sparkplug is fully separated from OSR urgency. If > > SP code exists, we simply jump to it, no need to maintain an > > installation request. > > - Each JumpLoop checks its dedicated FeedbackVector cache slot. > > If a valid target code object exists, we enter it *without* > > calling into runtime to fetch the code object. > > - Finally, OSR urgency still remains as the heuristic for > > requesting Turbofan OSR compile jobs. Note it no longer has a > > double purpose of being a generic untargeted installation > > request. > > > > With the new system in place, we can remove now-unnecessary > > hacks: > > > > - Early OSR tierup is replaced by the standard OSR system. Any > > present OSR code is automatically entered. > > - The synchronous OSR compilation fallback is removed. With > > precise installation (= per-JumpLoop-bytecode) we no longer > > have the problem of 'getting unlucky' with JumpLoop/cache entry > > mismatches. Execution has moved on while compiling? Simply spawn > > a new concurrent compile job. > > - Remove the synchronous (non-OSR) Turbofan compile request now > > that we always enter available OSR code as early as possible. > > - Tiering into Sparkplug no longer messes with OSR state. > > > > Bug: v8:12161 > > Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167 > > Commit-Queue: Jakob Linke <jgruber@chromium.org> > > Auto-Submit: Jakob Linke <jgruber@chromium.org> > > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Cr-Commit-Position: refs/heads/main@{#80147} > > Bug: v8:12161 > Change-Id: Ib3597cf1d99cdb5d0f2c5ac18e311914f376231d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606232 > Auto-Submit: Jakob Linke <jgruber@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/main@{#80167} Bug: v8:12161,chromium:1320189 Change-Id: Ibd9a2ab61f51ebb32a3f5a66f7c602faead71c3e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3620273Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#80306}
-
- 29 Apr, 2022 1 commit
-
-
Rohan Pavone authored
This reverts commit 91453880. Reason for revert: Breaking the Fuchsia Deterministic Builder Original change's description: > Reland "[osr] Use the new OSR cache" > > This is a reland of commit 91da3883 > > Fixed: Use an X register for JumpIfCodeTIsMarkedForDeoptimization > on arm64. > > Original change's description: > > [osr] Use the new OSR cache > > > > This CL switches over our OSR system to be based on the feedback > > vector osr caches. > > > > - OSRing to Sparkplug is fully separated from OSR urgency. If > > SP code exists, we simply jump to it, no need to maintain an > > installation request. > > - Each JumpLoop checks its dedicated FeedbackVector cache slot. > > If a valid target code object exists, we enter it *without* > > calling into runtime to fetch the code object. > > - Finally, OSR urgency still remains as the heuristic for > > requesting Turbofan OSR compile jobs. Note it no longer has a > > double purpose of being a generic untargeted installation > > request. > > > > With the new system in place, we can remove now-unnecessary > > hacks: > > > > - Early OSR tierup is replaced by the standard OSR system. Any > > present OSR code is automatically entered. > > - The synchronous OSR compilation fallback is removed. With > > precise installation (= per-JumpLoop-bytecode) we no longer > > have the problem of 'getting unlucky' with JumpLoop/cache entry > > mismatches. Execution has moved on while compiling? Simply spawn > > a new concurrent compile job. > > - Remove the synchronous (non-OSR) Turbofan compile request now > > that we always enter available OSR code as early as possible. > > - Tiering into Sparkplug no longer messes with OSR state. > > > > Bug: v8:12161 > > Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167 > > Commit-Queue: Jakob Linke <jgruber@chromium.org> > > Auto-Submit: Jakob Linke <jgruber@chromium.org> > > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Cr-Commit-Position: refs/heads/main@{#80147} > > Bug: v8:12161 > Change-Id: Ib3597cf1d99cdb5d0f2c5ac18e311914f376231d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606232 > Auto-Submit: Jakob Linke <jgruber@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/main@{#80167} Bug: v8:12161 Change-Id: I73e2d98660e9edfbe07a152a14402380ea9227de Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3615219Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Owners-Override: Deepti Gandluri <gdeepti@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#80287}
-
- 26 Apr, 2022 1 commit
-
-
Jakob Gruber authored
This is a reland of commit 91da3883 Fixed: Use an X register for JumpIfCodeTIsMarkedForDeoptimization on arm64. Original change's description: > [osr] Use the new OSR cache > > This CL switches over our OSR system to be based on the feedback > vector osr caches. > > - OSRing to Sparkplug is fully separated from OSR urgency. If > SP code exists, we simply jump to it, no need to maintain an > installation request. > - Each JumpLoop checks its dedicated FeedbackVector cache slot. > If a valid target code object exists, we enter it *without* > calling into runtime to fetch the code object. > - Finally, OSR urgency still remains as the heuristic for > requesting Turbofan OSR compile jobs. Note it no longer has a > double purpose of being a generic untargeted installation > request. > > With the new system in place, we can remove now-unnecessary > hacks: > > - Early OSR tierup is replaced by the standard OSR system. Any > present OSR code is automatically entered. > - The synchronous OSR compilation fallback is removed. With > precise installation (= per-JumpLoop-bytecode) we no longer > have the problem of 'getting unlucky' with JumpLoop/cache entry > mismatches. Execution has moved on while compiling? Simply spawn > a new concurrent compile job. > - Remove the synchronous (non-OSR) Turbofan compile request now > that we always enter available OSR code as early as possible. > - Tiering into Sparkplug no longer messes with OSR state. > > Bug: v8:12161 > Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167 > Commit-Queue: Jakob Linke <jgruber@chromium.org> > Auto-Submit: Jakob Linke <jgruber@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/main@{#80147} Bug: v8:12161 Change-Id: Ib3597cf1d99cdb5d0f2c5ac18e311914f376231d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606232 Auto-Submit: Jakob Linke <jgruber@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#80167}
-
- 25 Apr, 2022 2 commits
-
-
Nico Hartmann authored
This reverts commit 91da3883. Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20arm64%20-%20sim%20-%20pointer%20compression%20-%20builder/21150/overview Original change's description: > [osr] Use the new OSR cache > > This CL switches over our OSR system to be based on the feedback > vector osr caches. > > - OSRing to Sparkplug is fully separated from OSR urgency. If > SP code exists, we simply jump to it, no need to maintain an > installation request. > - Each JumpLoop checks its dedicated FeedbackVector cache slot. > If a valid target code object exists, we enter it *without* > calling into runtime to fetch the code object. > - Finally, OSR urgency still remains as the heuristic for > requesting Turbofan OSR compile jobs. Note it no longer has a > double purpose of being a generic untargeted installation > request. > > With the new system in place, we can remove now-unnecessary > hacks: > > - Early OSR tierup is replaced by the standard OSR system. Any > present OSR code is automatically entered. > - The synchronous OSR compilation fallback is removed. With > precise installation (= per-JumpLoop-bytecode) we no longer > have the problem of 'getting unlucky' with JumpLoop/cache entry > mismatches. Execution has moved on while compiling? Simply spawn > a new concurrent compile job. > - Remove the synchronous (non-OSR) Turbofan compile request now > that we always enter available OSR code as early as possible. > - Tiering into Sparkplug no longer messes with OSR state. > > Bug: v8:12161 > Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167 > Commit-Queue: Jakob Linke <jgruber@chromium.org> > Auto-Submit: Jakob Linke <jgruber@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/main@{#80147} Bug: v8:12161 Change-Id: I4a6955f4f20b6f3b13e98d5600c7c6a5205915bc No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605608 Auto-Submit: Nico Hartmann <nicohartmann@chromium.org> Owners-Override: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#80148}
-
Jakob Gruber authored
This CL switches over our OSR system to be based on the feedback vector osr caches. - OSRing to Sparkplug is fully separated from OSR urgency. If SP code exists, we simply jump to it, no need to maintain an installation request. - Each JumpLoop checks its dedicated FeedbackVector cache slot. If a valid target code object exists, we enter it *without* calling into runtime to fetch the code object. - Finally, OSR urgency still remains as the heuristic for requesting Turbofan OSR compile jobs. Note it no longer has a double purpose of being a generic untargeted installation request. With the new system in place, we can remove now-unnecessary hacks: - Early OSR tierup is replaced by the standard OSR system. Any present OSR code is automatically entered. - The synchronous OSR compilation fallback is removed. With precise installation (= per-JumpLoop-bytecode) we no longer have the problem of 'getting unlucky' with JumpLoop/cache entry mismatches. Execution has moved on while compiling? Simply spawn a new concurrent compile job. - Remove the synchronous (non-OSR) Turbofan compile request now that we always enter available OSR code as early as possible. - Tiering into Sparkplug no longer messes with OSR state. Bug: v8:12161 Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167 Commit-Queue: Jakob Linke <jgruber@chromium.org> Auto-Submit: Jakob Linke <jgruber@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#80147}
-
- 11 Apr, 2022 1 commit
-
-
Jakob Gruber authored
This is a reland of commit 51b99213 Fixed in reland: - bytecode_age was incorrectly still accessed as an int8 (instead of int16). - age and osr state were incorrectly reset on ia32 (16-bit write instead of 32-bit). Original change's description: > [osr] Add an install-by-offset mechanism > > .. for concurrent OSR. There, the challenge is to hit the correct > JumpLoop bytecode once compilation completes, since execution has > moved on in the meantime. > > This CL adds a new mechanism to request installation at a specific > bytecode offset. We add a new `osr_install_target` field to the > BytecodeArray: > > bitfield struct OSRUrgencyAndInstallTarget extends uint16 { > osr_urgency: uint32: 3 bit; > osr_install_target: uint32: 13 bit; > } > > // [...] > osr_urgency_and_install_target: OSRUrgencyAndInstallTarget; > bytecode_age: uint16; // Only 3 bits used. > // [...] > > Note urgency and install target are packed into one 16 bit field, > we can thus merge both checks into one comparison within JumpLoop. > Note also that these fields are adjacent to the bytecode age; we > still reset both OSR state and age with a single (now 32-bit) > store. > > The install target is the lowest 13 bits of the bytecode offset. > When set, every reached JumpLoop will check `is this my offset?`, > and if yes, jump into runtime to tier up. > > Drive-by: Rename BaselineAssembler::LoadByteField to LoadWord8Field. > > Bug: v8:12161 > Change-Id: I275d468b19df3a4816392a2fec0713a8d211ef80 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571812 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Jakob Linke <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/main@{#79853} Bug: v8:12161 Change-Id: I7c59b2a2aacb1d7d40fdf39396ec9d8d48b0b9ac Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3578543Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79911}
-
- 07 Apr, 2022 2 commits
-
-
Leszek Swirski authored
This reverts commit 51b99213. Reason for revert: Speculative revert for MSAN failure https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/43080/overview Original change's description: > [osr] Add an install-by-offset mechanism > > .. for concurrent OSR. There, the challenge is to hit the correct > JumpLoop bytecode once compilation completes, since execution has > moved on in the meantime. > > This CL adds a new mechanism to request installation at a specific > bytecode offset. We add a new `osr_install_target` field to the > BytecodeArray: > > bitfield struct OSRUrgencyAndInstallTarget extends uint16 { > osr_urgency: uint32: 3 bit; > osr_install_target: uint32: 13 bit; > } > > // [...] > osr_urgency_and_install_target: OSRUrgencyAndInstallTarget; > bytecode_age: uint16; // Only 3 bits used. > // [...] > > Note urgency and install target are packed into one 16 bit field, > we can thus merge both checks into one comparison within JumpLoop. > Note also that these fields are adjacent to the bytecode age; we > still reset both OSR state and age with a single (now 32-bit) > store. > > The install target is the lowest 13 bits of the bytecode offset. > When set, every reached JumpLoop will check `is this my offset?`, > and if yes, jump into runtime to tier up. > > Drive-by: Rename BaselineAssembler::LoadByteField to LoadWord8Field. > > Bug: v8:12161 > Change-Id: I275d468b19df3a4816392a2fec0713a8d211ef80 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571812 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Jakob Linke <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/main@{#79853} Bug: v8:12161 Change-Id: I0c47499544465c80b5b23a492c00ec1c62815caa No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3576121 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Owners-Override: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#79855}
-
Jakob Gruber authored
.. for concurrent OSR. There, the challenge is to hit the correct JumpLoop bytecode once compilation completes, since execution has moved on in the meantime. This CL adds a new mechanism to request installation at a specific bytecode offset. We add a new `osr_install_target` field to the BytecodeArray: bitfield struct OSRUrgencyAndInstallTarget extends uint16 { osr_urgency: uint32: 3 bit; osr_install_target: uint32: 13 bit; } // [...] osr_urgency_and_install_target: OSRUrgencyAndInstallTarget; bytecode_age: uint16; // Only 3 bits used. // [...] Note urgency and install target are packed into one 16 bit field, we can thus merge both checks into one comparison within JumpLoop. Note also that these fields are adjacent to the bytecode age; we still reset both OSR state and age with a single (now 32-bit) store. The install target is the lowest 13 bits of the bytecode offset. When set, every reached JumpLoop will check `is this my offset?`, and if yes, jump into runtime to tier up. Drive-by: Rename BaselineAssembler::LoadByteField to LoadWord8Field. Bug: v8:12161 Change-Id: I275d468b19df3a4816392a2fec0713a8d211ef80 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571812Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79853}
-
- 03 Mar, 2022 1 commit
-
-
jameslahm authored
- add CopyDataPropertiesWithExcludedProperties intrinsic - add CopyDataPropertiesWithExcludedProperties_Baseline intrinsic Bug: v8:11614 Change-Id: Ie6a3db4c9edda40ecf84b8d1107e70fd7ff0d5fb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3470349Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#79342}
-
- 23 Feb, 2022 1 commit
-
-
Jakob Gruber authored
- Move feedback / SP into TieringManager. - Rename OnInterruptTickFromBytecode to OnInterruptTick (it's called from both Code and Bytecode). - Remove the SealHandleScope / HandleScope dance. Bug: v8:7700 Change-Id: I800542deb3805097a589b7766907efb6f40c7dae Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3467875Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79220}
-
- 17 Jan, 2022 1 commit
-
-
Patrick Thier authored
The receiver is included unconditionally on all platforms (kJSArgcIncludesReceiver is always true). Remove all usages of kJSArgcIncludesReceiver from the code. Bug: v8:11112 Change-Id: I7d62e6de65b73fe6d8c3293f32b500b760b08a3e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322980Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/main@{#78642}
-
- 07 Sep, 2021 1 commit
-
-
Patrick Thier authored
The receiver is now always included in the actual argument count and the formal parameter count. kDontAdaptArgumentsSentinel is changed from UINT16_MAX to 0 to preserve the maximum allowed declared parameters. The build flag activating the changes is not set for any architecture yet. Bug: v8:11112 Change-Id: I48a4969137949a1b4d1f47545209bb22b64e7e05 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3140608 Commit-Queue: Patrick Thier <pthier@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Omer Katz <omerkatz@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/main@{#76699}
-
- 27 Aug, 2021 1 commit
-
-
Leszek Swirski authored
StaGlobal didn't write the accumulator, but the baseline implementation assumed that it could preserve the accumulator by taking the return value of the StoreGlobalIC. This almost always worked, except for setters on the global object. Fix this by marking StaGlobal as clobbering the accumulator, same as StaNamedProperty (StaNamedProperty needs to do this anyway to avoid inlined setters from needing to create accumulator-preserving frames; StaGlobal would have needed the same thing if we'd ever inlined setters for it). Also, add a new debug scope, EnsureAccumulatorPreservedScope, to the baseline compiler, which checks if the accumulator value is preserved across non-accumulator-writing bytecodes. This found a (benign) bug with ForInPrepare, so fix that too. Fixed: chromium:1242306 Change-Id: I220b5b1c41010c16ac9f944cbd55d2705c299434 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3122325 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#76525}
-
- 19 Aug, 2021 1 commit
-
-
Patrick Thier authored
- Introduce helper to push arguments onto the stack (Standalone this change doesn't make a lot of sense, but is in preparation for including the receiver in argc). - Introduce helper to shift arguments already on the stack to make room for new arguments (Varargs). - arm64 is not included because a) there was already a helper similar to ShiftArguments and b) PushArguments is not similar enough to make sense for arm64 because of small differences (e.g. also pushing the function) in conjunction with stack alignment. Drive-by: Use masm DropArguments in Sparkplug EmitReturn Bug: v8:11112 Change-Id: Id7a3a5f025abb19e2a52dae27b3b484fe87e9faf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097275Reviewed-by: Victor Gomes <victorgomes@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/main@{#76392}
-
- 04 Aug, 2021 1 commit
-
-
Patrick Thier authored
Maximum frame size (in bytes) is used to check for stack overflows in the prologue. The maximum number of call arguments is pre-calculated and included in this check. However the count was added to the frame size wihout converting the count to bytes, resulting in inaccurate stack overflow checks. Bug: chromium:1235182 Change-Id: I21bca4e183fccfd055f2f1d5a40b71651c14b911 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3071399Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/master@{#76090}
-
- 24 Jun, 2021 1 commit
-
-
Camillo Bruni authored
This is a reland of 2588380d Fixes arm compilation. Original change's description: > [assembler][arm64][arm][ia32] Add more Assembler::CodeComment > > Use more code comments to better document generated assembler code. > This CL also attaches a CodeComment to FrameScope. > > Change-Id: I45afc3e4078dc161316b877fbbd1ae8bcd6e821d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2964392 > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Victor Gomes <victorgomes@chromium.org> > Commit-Queue: Camillo Bruni <cbruni@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75277} Change-Id: I150c9166e0d31e4af857f76c567b829d16da87e4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2976651Reviewed-by: Victor Gomes <victorgomes@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#75351}
-
- 23 Jun, 2021 1 commit
-
-
Mihir Shah authored
The change is made since for switch statements with lots of cases, where each case is a constant integer, the emitted bytecode is still a series of jumps, when we can instead use a jump table. If there are 6 or more cases (similar to GCC) of Smi literals, and if the max Smi case minus the min Smi case is not more than 3 times the number of cases, we use a jump table up front to handle Smi's, and then use traditional if-else logic for the rest of the cases. We then use the jump table in interpreter/bytecode-jump-table to do the optimization. This tries to go off issue 9738 in v8's issue tracker. It is not exactly the same, since that recommends doing the work at JIT-time, but has similar ideas. It also partially goes off issue 10764. Bug: v8:9738 Change-Id: Ic805682ee3abf9ce464bb733b427fa0c83a6e10c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2904926Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#75323}
-
- 21 Jun, 2021 2 commits
-
-
Nico Hartmann authored
This reverts commit 2588380d. Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Arm%20-%20debug%20builder/34664/overview Original change's description: > [assembler][arm64][arm][ia32] Add more Assembler::CodeComment > > Use more code comments to better document generated assembler code. > This CL also attaches a CodeComment to FrameScope. > > Change-Id: I45afc3e4078dc161316b877fbbd1ae8bcd6e821d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2964392 > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Victor Gomes <victorgomes@chromium.org> > Commit-Queue: Camillo Bruni <cbruni@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75277} Change-Id: I6d36535ca96133cc83b3d6194a3d53889f735499 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972826Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#75278}
-
Camillo Bruni authored
Use more code comments to better document generated assembler code. This CL also attaches a CodeComment to FrameScope. Change-Id: I45afc3e4078dc161316b877fbbd1ae8bcd6e821d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2964392Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Victor Gomes <victorgomes@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#75277}
-
- 10 Jun, 2021 2 commits
-
-
Liu Yu authored
This is a reland of febfbb21 Original change's description: > [sparkplug] Adjust compare and jump function in sparkplug > > Mips and risc-v do not have the flag register and can not decide > whether to jump through flags in JumpIf(); > > Therefor, we merge the comparison with the jump; > > Bug: v8:11803 > > Change-Id: If53752da93b97e8ff65affdfe99e5de8e1a1493f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2921034 > Auto-Submit: Liu yu <liuyu@loongson.cn> > Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75001} Bug: v8:11803 Change-Id: Ib3cb89d8a9f59aad3fbd857881699e84e8fcd8aa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2945538 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#75078}
-
Camillo Bruni authored
Migrate the remaining architectures to the new callee save RecordWrite approach. Bug: v8:11420 Change-Id: I9da56cbb5bf8c6ca4bcc7c0e2a1233e2f5ef587c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944844 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#75075}
-
- 08 Jun, 2021 2 commits
-
-
Zhao Jiazhong authored
This reverts commit febfbb21. Reason for revert: Introduced new bugs: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64%20-%20debug/34472/overview Original change's description: > [sparkplug] Adjust compare and jump function in sparkplug > > Mips and risc-v do not have the flag register and can not decide > whether to jump through flags in JumpIf(); > > Therefor, we merge the comparison with the jump; > > Bug: v8:11803 > > Change-Id: If53752da93b97e8ff65affdfe99e5de8e1a1493f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2921034 > Auto-Submit: Liu yu <liuyu@loongson.cn> > Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75001} Bug: v8:11803 Change-Id: Ic982564ccdef9a07bf3a5fb4745a11cfa178cc0e No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2946818 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Cr-Commit-Position: refs/heads/master@{#75005}
-
Liu Yu authored
Mips and risc-v do not have the flag register and can not decide whether to jump through flags in JumpIf(); Therefor, we merge the comparison with the jump; Bug: v8:11803 Change-Id: If53752da93b97e8ff65affdfe99e5de8e1a1493f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2921034 Auto-Submit: Liu yu <liuyu@loongson.cn> Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#75001}
-
- 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}
-
- 02 Jun, 2021 1 commit
-
-
Leszek Swirski authored
Since we always call the out-of-line Prologue, we can preload the accumulator in there with undefined instead of having to emit an undefined load in every Sparkplug code header. Change-Id: Ie0385316b0ee8bf96cd0069cda0496d05a4fb1eb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2933144Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#74919}
-
- 11 May, 2021 1 commit
-
-
Camillo Bruni authored
Convert StoreOrigin, TypeOfMode, SaveFPRegsMode and ArgvMode to enum classes with k-prefixed values. Change-Id: Ib6ca3a9995297e8303a7e013b1d829613c0db510 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2885042Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Zhi An Ng <zhin@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#74497}
-
- 21 Apr, 2021 2 commits
-
-
Leszek Swirski authored
For handles and external refs, use Move32BitImmediate directly rather than mov -- mov will first try more compact encodings which will almost certainly fail for embedded pointers, so it's not worth trying to use it in baseline compilation where the compiler speed matters. Bug: v8:11420 Change-Id: Ic0ed9f95d28302ae9737567aa863dc93666239e1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843814 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#74103}
-
Leszek Swirski authored
Similar to the recent change to --code-comments, make --debug-code a build-time enabled flag, enabled by default on debug builds. This also removes the emit_debug_code() option from the assembler, instead using the flag directly (there were no cases where this option didn't match the global flag). Change-Id: Ic26b0d37b615a055508c9dda099ffbe979eae030 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843348 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#74095}
-
- 20 Apr, 2021 1 commit
-
-
Camillo Bruni authored
- Add v8_code_comments to allow runtime-enabled code comments with --code-comments - v8_code_comments is enable by default in debug mode - Make MacroAssembler::RecordComment helper inlineable to remove call and check overheads when v8_code_comments = false - Make FLAG_code_comments readonly if v8_code_comments = false and benefit from dead-code elimination This saves roughly 5% CompileBaselineVisit time in sparkplug on a 5MiB JS file. Bug: v8:11420 Change-Id: I1174ab37b4bbe1ff8880416c1f6a6e28377a962c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2824428Reviewed-by: Bill Budge <bbudge@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#74055}
-
- 16 Apr, 2021 3 commits
-
-
Leszek Swirski authored
This is a reland of ae0752df Reland fixes: * Remove UNREACHABLE() from constexpr switch, since we don't have a CONSTEXPR_UNREACHABLE() (it's ok, the switch is exhaustive for the enum anyway). * Fix IsRegisterArray trait to use public inheritance and size_t for std::array size. Original change's description: > [codegen] Add static interface descriptors > > Add a new CRTP StaticCallInterfaceDescriptor class, which provides > static constexpr getters for a descriptor's registers, parameter counts, > and so on. Each CallInterfaceDescriptor subclass is changed to extend > StaticCallInterfaceDescriptor, with StaticCallInterfaceDescriptor itself > extending CallInterfaceDescriptor to still provide a dynamic lookup > where needed. > > StaticCallInterfaceDescriptor provides a couple of customisation points, > where it reads its CRTP derived descriptor's static fields and > functions, with default fallbacks where appropriate. With these > customisation points, the definition of CallInterfaceDescriptor > subclasses is simplified to: > > a) Providing parameter names (as before) > b) Providing parameter types (as before) > c) Optionally setting flags (like kNoContext or kAllowVarArgs) as > static booleans on the class. > d) Optionally providing a `registers()` method that returns a > std::array<Register, N> of registers that may be used for > parameters (if not provided, this defaults to the implementation > specific default register set). > > Parameter registers (and register count) are automagically set based on > the number of parameters and number of given registers, with extra magic > to ignore no_reg registers (to reduce ia32 special casing). The > CallInterfaceDescriptorData is initialized based on these static > functions, rather than manual per-descriptor initializers. > > This allows us to skip loading descriptors dynamically for CallBuiltin > in Sparkplug, and instead lets us use a bit of template magic to > statically set up arguments for the calls. Any other users of statically > known descriptors will also benefit, thanks to C++ picking the static > methods over the dynamic methods on the base class when available. > > Because we can remove various virtual functions and trigger heavier > inlining of constantly known values, binary size slightly decreases with > this change. > > Note that torque-generated descriptors are changed to use the same magic, > rather than having Torque-specific magic, for consistency. > > Bug: v8:11420 > Change-Id: Icc5e238b6313a08734feb564204a13226b450c22 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2814518 > Auto-Submit: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73996} TBR=nicohartmann@chromium.org,clemensb@chromium.org,ishell@chromium.org,clemensb@chromium.org Bug: v8:11420 Change-Id: Icd1f6cdb3c178e74460044b1e9623139929ceba8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2831872Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#74010}
-
Leszek Swirski authored
This reverts commit ae0752df. Reason for revert: Predictably, constexpr issues on non-clang compilers. Original change's description: > [codegen] Add static interface descriptors > > Add a new CRTP StaticCallInterfaceDescriptor class, which provides > static constexpr getters for a descriptor's registers, parameter counts, > and so on. Each CallInterfaceDescriptor subclass is changed to extend > StaticCallInterfaceDescriptor, with StaticCallInterfaceDescriptor itself > extending CallInterfaceDescriptor to still provide a dynamic lookup > where needed. > > StaticCallInterfaceDescriptor provides a couple of customisation points, > where it reads its CRTP derived descriptor's static fields and > functions, with default fallbacks where appropriate. With these > customisation points, the definition of CallInterfaceDescriptor > subclasses is simplified to: > > a) Providing parameter names (as before) > b) Providing parameter types (as before) > c) Optionally setting flags (like kNoContext or kAllowVarArgs) as > static booleans on the class. > d) Optionally providing a `registers()` method that returns a > std::array<Register, N> of registers that may be used for > parameters (if not provided, this defaults to the implementation > specific default register set). > > Parameter registers (and register count) are automagically set based on > the number of parameters and number of given registers, with extra magic > to ignore no_reg registers (to reduce ia32 special casing). The > CallInterfaceDescriptorData is initialized based on these static > functions, rather than manual per-descriptor initializers. > > This allows us to skip loading descriptors dynamically for CallBuiltin > in Sparkplug, and instead lets us use a bit of template magic to > statically set up arguments for the calls. Any other users of statically > known descriptors will also benefit, thanks to C++ picking the static > methods over the dynamic methods on the base class when available. > > Because we can remove various virtual functions and trigger heavier > inlining of constantly known values, binary size slightly decreases with > this change. > > Note that torque-generated descriptors are changed to use the same magic, > rather than having Torque-specific magic, for consistency. > > Bug: v8:11420 > Change-Id: Icc5e238b6313a08734feb564204a13226b450c22 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2814518 > Auto-Submit: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73996} Bug: v8:11420 Change-Id: Ie5469c9253fc140590ac30b72db6eb1d93f86806 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2831485 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#74000}
-
Leszek Swirski authored
Add a new CRTP StaticCallInterfaceDescriptor class, which provides static constexpr getters for a descriptor's registers, parameter counts, and so on. Each CallInterfaceDescriptor subclass is changed to extend StaticCallInterfaceDescriptor, with StaticCallInterfaceDescriptor itself extending CallInterfaceDescriptor to still provide a dynamic lookup where needed. StaticCallInterfaceDescriptor provides a couple of customisation points, where it reads its CRTP derived descriptor's static fields and functions, with default fallbacks where appropriate. With these customisation points, the definition of CallInterfaceDescriptor subclasses is simplified to: a) Providing parameter names (as before) b) Providing parameter types (as before) c) Optionally setting flags (like kNoContext or kAllowVarArgs) as static booleans on the class. d) Optionally providing a `registers()` method that returns a std::array<Register, N> of registers that may be used for parameters (if not provided, this defaults to the implementation specific default register set). Parameter registers (and register count) are automagically set based on the number of parameters and number of given registers, with extra magic to ignore no_reg registers (to reduce ia32 special casing). The CallInterfaceDescriptorData is initialized based on these static functions, rather than manual per-descriptor initializers. This allows us to skip loading descriptors dynamically for CallBuiltin in Sparkplug, and instead lets us use a bit of template magic to statically set up arguments for the calls. Any other users of statically known descriptors will also benefit, thanks to C++ picking the static methods over the dynamic methods on the base class when available. Because we can remove various virtual functions and trigger heavier inlining of constantly known values, binary size slightly decreases with this change. Note that torque-generated descriptors are changed to use the same magic, rather than having Torque-specific magic, for consistency. Bug: v8:11420 Change-Id: Icc5e238b6313a08734feb564204a13226b450c22 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2814518 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73996}
-
- 29 Mar, 2021 1 commit
-
-
Patrick Thier authored
With the addition of deoptimizing to baseline, we mark the begin of every bytecode as a valid jump target in baseline code (Required for CFI on arm64). Therefore we can omit marking excpetion handler positions and binds at the beginning of the bytecode as valid jump targets now. Bug: v8:11420 Change-Id: Id173dacb5534b680c5c3796c78e2a2c2288e5e0a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2786841 Auto-Submit: Patrick Thier <pthier@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#73702}
-
- 25 Mar, 2021 1 commit
-
-
Patrick Thier authored
This is a reland of e3ccb538 No changes for the reland. This CL was speculatively reverted, but was not the cause of the problem. TBR=jgruber@chromium.org Original change's description: > Reland "[sparkplug][deoptimizer] Deoptimize to baseline." > > This is a reland of bdcd7d79 > > Handle lazy deopts when the current bytecode is JumpLoop. > Instead of advancing to the next bytecode, re-execute the JumpLoop. > > TBR=jgruber@chromium.org, neis@chromium.org > > Original change's description: > > [sparkplug][deoptimizer] Deoptimize to baseline. > > > > If we have baseline code, deoptimize to baseline instead of the > > interpreter. The process is similar to deopting to the interpreter. > > We just use different builtins > > (BaselineEnterAtBytecode/BaselineEnterAtNextBytecode) instead of > > InterpreterEnterBytecodeDispatch/InterpreterEnterBytecodeAdvance, that > > patch an interpreter frame to a baseline frame and continue execution in > > baseline code (based on the deopt type, at the current or next > > bytecode). > > > > Bug: v8:11420 > > Change-Id: Iabaefb36c05155a435c7b380906a86d9b9d549fa > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695591 > > Commit-Queue: Patrick Thier <pthier@chromium.org> > > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Georg Neis <neis@chromium.org> > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#73609} > > Bug: v8:11420 > Change-Id: Ib8cac028121188ddc23ff29377760ed684eb7392 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783035 > Reviewed-by: Patrick Thier <pthier@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Patrick Thier <pthier@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73636} Bug: v8:11420 Change-Id: I7fbbb73a4fdaeab8b294862ee6ae952928c57994 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2784695 Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Auto-Submit: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/master@{#73656}
-
- 24 Mar, 2021 3 commits
-
-
Deepti Gandluri authored
This reverts commit e3ccb538. Reason for revert: Speculative revert for ARM 64 CFI fails - https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20CFI/5174? Original change's description: > Reland "[sparkplug][deoptimizer] Deoptimize to baseline." > > This is a reland of bdcd7d79 > > Handle lazy deopts when the current bytecode is JumpLoop. > Instead of advancing to the next bytecode, re-execute the JumpLoop. > > TBR=jgruber@chromium.org, neis@chromium.org > > Original change's description: > > [sparkplug][deoptimizer] Deoptimize to baseline. > > > > If we have baseline code, deoptimize to baseline instead of the > > interpreter. The process is similar to deopting to the interpreter. > > We just use different builtins > > (BaselineEnterAtBytecode/BaselineEnterAtNextBytecode) instead of > > InterpreterEnterBytecodeDispatch/InterpreterEnterBytecodeAdvance, that > > patch an interpreter frame to a baseline frame and continue execution in > > baseline code (based on the deopt type, at the current or next > > bytecode). > > > > Bug: v8:11420 > > Change-Id: Iabaefb36c05155a435c7b380906a86d9b9d549fa > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695591 > > Commit-Queue: Patrick Thier <pthier@chromium.org> > > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Georg Neis <neis@chromium.org> > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#73609} > > Bug: v8:11420 > Change-Id: Ib8cac028121188ddc23ff29377760ed684eb7392 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783035 > Reviewed-by: Patrick Thier <pthier@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Patrick Thier <pthier@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73636} Bug: v8:11420 Change-Id: Icd797b4979a114a2a627e12c8bb7d2215df03182 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2785074Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Reviewed-by: Bill Budge <bbudge@chromium.org> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#73643}
-
Patrick Thier authored
This is a reland of bdcd7d79 Handle lazy deopts when the current bytecode is JumpLoop. Instead of advancing to the next bytecode, re-execute the JumpLoop. TBR=jgruber@chromium.org, neis@chromium.org Original change's description: > [sparkplug][deoptimizer] Deoptimize to baseline. > > If we have baseline code, deoptimize to baseline instead of the > interpreter. The process is similar to deopting to the interpreter. > We just use different builtins > (BaselineEnterAtBytecode/BaselineEnterAtNextBytecode) instead of > InterpreterEnterBytecodeDispatch/InterpreterEnterBytecodeAdvance, that > patch an interpreter frame to a baseline frame and continue execution in > baseline code (based on the deopt type, at the current or next > bytecode). > > Bug: v8:11420 > Change-Id: Iabaefb36c05155a435c7b380906a86d9b9d549fa > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695591 > Commit-Queue: Patrick Thier <pthier@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73609} Bug: v8:11420 Change-Id: Ib8cac028121188ddc23ff29377760ed684eb7392 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783035Reviewed-by: Patrick Thier <pthier@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/master@{#73636}
-
Sathya Gunasekaran authored
This reverts commit bdcd7d79. Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Blink%20Linux%20Future/7996/blamelist Original change's description: > [sparkplug][deoptimizer] Deoptimize to baseline. > > If we have baseline code, deoptimize to baseline instead of the > interpreter. The process is similar to deopting to the interpreter. > We just use different builtins > (BaselineEnterAtBytecode/BaselineEnterAtNextBytecode) instead of > InterpreterEnterBytecodeDispatch/InterpreterEnterBytecodeAdvance, that > patch an interpreter frame to a baseline frame and continue execution in > baseline code (based on the deopt type, at the current or next > bytecode). > > Bug: v8:11420 > Change-Id: Iabaefb36c05155a435c7b380906a86d9b9d549fa > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695591 > Commit-Queue: Patrick Thier <pthier@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73609} Bug: v8:11420 Change-Id: Ie8b936df343b9194c0a6e50e0c44b67c0d9a012d No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783030 Auto-Submit: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#73621}
-