- 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}
-
- 14 Apr, 2022 1 commit
-
-
Jakob Gruber authored
This is a reland of commit a4216b7b Original change's description: > [osr] Extract extended OSR checks to BaselineOnStackReplacement builtin > > .. to reduce Sparkplug code size. > > Bug: v8:12161 > Change-Id: I4029a75dfa37f716c285ce27153c077a0a82a341 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3576119 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Jakob Linke <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/main@{#79962} Bug: v8:12161 Change-Id: I69afd0832d7ca447b5481651ef47ebaa8d023ded Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3585943 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@{#79980}
-
- 13 Apr, 2022 2 commits
-
-
Tobias Tebbi authored
This reverts commit a4216b7b. Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/43174/overview Original change's description: > [osr] Extract extended OSR checks to BaselineOnStackReplacement builtin > > .. to reduce Sparkplug code size. > > Bug: v8:12161 > Change-Id: I4029a75dfa37f716c285ce27153c077a0a82a341 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3576119 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Jakob Linke <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/main@{#79962} Bug: v8:12161 Change-Id: I382609d0b8cd951a3df5c9c834fe7071eb90faa5 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3584121 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Owners-Override: Tobias Tebbi <tebbi@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#79966}
-
Jakob Gruber authored
.. to reduce Sparkplug code size. Bug: v8:12161 Change-Id: I4029a75dfa37f716c285ce27153c077a0a82a341 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3576119Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79962}
-
- 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}
-
- 17 Mar, 2022 1 commit
-
-
Jakob Gruber authored
- Restructure the runtime function implementation. - Rename osr_loop_nesting_level to osr_urgency and add helpers. The motivation for the latter: I've always struggled with the `osr_loop_nesting_level` term; it neither matches terminology of what it's compared against (= the loop depth), nor implies what it's used for (= osr is triggered when `loop depth < osr nesting level`). In this CL it's renamed to `osr_urgency` to reflect that as urgency rises, we consider more and more loops as OSR candidates. Bug: v8:12161 Change-Id: I194ec5a3f1f02526641af1c7796ee0956b6fd3a1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3528735Reviewed-by: Patrick Thier <pthier@chromium.org> Reviewed-by: Shu-yu Guo <syg@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79509}
-
- 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}
-
- 16 Dec, 2021 2 commits
-
-
Leszek Swirski authored
We don't need this with reversed arguments. Change-Id: I86c5183bccc62ba1727080ebbd685df083608d2f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3344947 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/main@{#78396}
-
Igor Sheludko authored
... in order to avoid Code <-> CodeT conversions in builtins. This CL changes the meaning of RelocInfo::CODE_TARGET which now expects CodeT objects as a code target. In order to reduce code churn this CL makes BUILTIN_CODE and friends return CodeT instead of Code. In the follow-up CLs BUILTIN_CODET and friends will be removed. Bug: v8:11880 Change-Id: Ib8f60973e55c60fc62ba84707471da388f8201b4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3338483Reviewed-by: Patrick Thier <pthier@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#78393}
-
- 25 Nov, 2021 1 commit
-
-
Hao Xu authored
Some of the JumpIf Bytecode Handlers will load the jump offset from bytecode array or constant pool before checking whether the condition is matched, and this jump offset is unused if the jump not actually happens. This CL move the Load operations to the branch on which the condition is matched. Bug: v8:12431 Change-Id: I3cb2fa7447ee2a9cb514148efb605617f95b1b68 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3300994 Commit-Queue: Hao A Xu <hao.a.xu@intel.com> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#78088}
-
- 30 Sep, 2021 1 commit
-
-
Marja Hölttä authored
It's confusing that we have CSA_CHECK and CSA_ASSERT and it's not clear from the names that the former works in release mode and the latter only in debug mode. Renaming CSA_ASSERT to CSA_DCHECK makes it clear what it does. So now we have CSA_CHECK and CSA_DCHECK and they're not confusing. This also renames assert() in Torque to dcheck(). Bug: v8:12244 Change-Id: I6f25d431ebc6eec7ebe326b6b8ad3a0ac5e9a108 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3190104Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Shu-yu Guo <syg@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/main@{#77160}
-
- 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}
-
- 06 Sep, 2021 1 commit
-
-
Leszek Swirski authored
Remove the BaselineData intermediate structure for baseline code, and write the baseline Code object into the SharedFunctionInfo directly. We still need a pointer to the BytecodeArray/InterpreterData, so re-use the Code object's deoptimization data slot for this (baseline code doesn't have deoptimization data). A consequence of this is that the BytecodeArray pointer becomes immutable when there is baseline code. This means that we cannot install a debug BytecodeArray while baseline code is active (we have to flush it first), and we can't tier-up code with debug BytecodeArray to baseline. Change-Id: I53b93ec4d4c64b833603d7992f246982fcd97596 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3118548 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#76675}
-
- 16 Aug, 2021 1 commit
-
-
Yu Yin authored
Bug: v8:12008 Change-Id: I2e1d918a1370dae1e15919fbf02d69cbe48f63bf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3089095Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#76308}
-
- 12 Aug, 2021 1 commit
-
-
Ross McIlroy authored
These are no longer enabled, so remove the code mitigation logic from the codebase. BUG=chromium:1003890 Change-Id: I536bb1732e8463281c21da446bbba8f47ede8ebe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3045704 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#76256}
-
- 23 Jul, 2021 1 commit
-
-
Leszek Swirski authored
Change the folded interrupt check to be on JumpLoop only, to avoid calling it from Return. The call from Return could cause spurious stack overflows, which interacted poorly with async functions that had already resolved their promise. Now the bytecode budget interrupt function is split into two functions, one which does the stack check and one which doesn't. The former is still called from JumpLoop, the latter is called from Return. Bug: chromium:1231952, chromium:1232105 Change-Id: I8c4e2937f64b5f8fdbd6c1fcb2a76ec5f090ae3c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3049076Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#75891}
-
- 19 Jul, 2021 1 commit
-
-
Seth Brenith authored
I've noticed a few places where class fields as defined in Torque have different names than the corresponding accessors in the C++ class. I think they should match. Most of this change is just mechanically updating the various places that use k##Field##Offset for those fields. Change-Id: I8ba52aed7f6a1cd6b2d71158f71150b66c2c0da0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3027263 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#75796}
-
- 07 Jun, 2021 2 commits
-
-
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}
-
Seth Brenith authored
The flag --trace-ignition-dispatches has been broken for a long time, since it was not designed to work with bytecode handlers that are generated ahead of time by mksnapshot. This splits the existing --trace-ignition-dispatches logic into two separate parts: 1. A gn argument which instructs mksnapshot to include dispatch counting in the bytecode handlers, and ensures that the Interpreter allocates the array of counters, and 2. A runtime flag which enables the ignition-statistics extension which implements the JS-accessible function getIgnitionDispatchCounters(). Change-Id: I89323425697f5641451f67b9ddcc0303b8ca209f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2937564Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#74992}
-
- 17 May, 2021 1 commit
-
-
Fanchen Kong authored
This CL makes a call to CollectCallFeedback from Ignition load the receiver lazily, which may improve the performance of Octane/{Richards, Delta-Blue} with --no-opt for 1-3%. Bug: chromium:1207349 Change-Id: I5fb09d5c5662ef8714acf71dd7341d3164b44f93 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2895358Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Fanchen Kong <fanchen.kong@intel.com> Cr-Commit-Position: refs/heads/master@{#74580}
-
- 06 May, 2021 1 commit
-
-
Fanchen Kong authored
When a function is invoked by prototype.apply, it may undergo following transformation in the JSCallReducer: receiver.apply(this, args) -> this.receiver(...args) Since the new target (also the receiver of apply()) is not collected to the feedback slot, further speculative optimization on the new target is not available if the new target is not a heapconstant. With this CL, the receiver will be collected to the feedback instead of the target if the target is a prototype.apply. It may improve the performance of the following usecase by ~80%. function reduceArray(func, arr, r) { for (var i = 0, len = arr.length; i < len; i++) { r = func.apply(null, r, arr[i]); } return r; } var a = 0; for (var i = 0; i < 10000000; i++) { a += reduceArray(Math.imul, [5,6,2,3,7,6,8,3,7,9,2,5,], 1); } console.log(a); This CL also improves the runTime score of JetStream2/richards-wasm by ~45% in default, ~60% with --turbo-inline-js-wasm-calls. Change-Id: I542eb8d3fcb592f4e0993af93ba1af70e89c3982 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639813 Commit-Queue: Fanchen Kong <fanchen.kong@intel.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#74413}
-
- 29 Apr, 2021 1 commit
-
-
Benedikt Meurer authored
The "Restart frame" feature was implemented as part of LiveEdit and primarily used to support LiveEdit of active functions, but that was previously disabled as part of https://crrev.com/c/2846892 because it's too brittle and causes crashes when using seemingly unrelated features. The "Restart frame" feature was also available as a context menu item separately in the DevTools front-end, but that was also already removed as part of https://crrev.com/c/2854681 earlier. So all uses are gone now. This change works by marking Debugger.restartFrame as deprecated and having it respond with a ServerError all the time. It thus allows us to remove a whole bunch of machinery that was essentially just put in various places to support the restart_fp_ magic. In particular the debugger no longer needs any machine specific builtins now. Bug: chromium:1195927 Change-Id: I1153ba6b00e979620af57dd9f58aa1c035ec4484 Fixed: chromium:1203606 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2854750Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#74276}
-
- 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}
-
- 06 Apr, 2021 1 commit
-
-
Patrick Thier authored
This is a reland of b9c521d0. Fixes crashes by calling kInstallBaselineCode from BaselineEntry if needed, i.e. when there is no feedback vector (required a bit of register rejiggling). This can happen with cross-realm calls. The OSR arming is stored as part of the BytecodeArray and therefore shared across realms. Original change's description: > [sparkplug] OSR Ignition -> Sparkplug > > Add support for OSR to baseline code. > We compile baseline and perform OSR immediately when the bytecode budget > interrupt hits. > > Drive-by: Clean-up deoptimizer special handling of JumpLoop by using > the newly introduced GetBaselinePCForNextExecutedBytecode instead of > GetBaselineEndPCForBytecodeOffset. > > Bug: v8:11420 > Change-Id: Ifbea264d4a83a127dd2a11e28626bf2a5e8aca59 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2784687 > Commit-Queue: Patrick Thier <pthier@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73677} Bug: v8:11420 Change-Id: I67325450514ed5a1170b730b1dd59fa6acc6e1d8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2800112Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/master@{#73803}
-
- 25 Mar, 2021 2 commits
-
-
Deepti Gandluri authored
This reverts commit 52393b90. Reason for revert: Reverting for TSAN fails - https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20no-concurrent-marking/3061 Original change's description: > [sparkplug] OSR Ignition -> Sparkplug > > Add support for OSR to baseline code. > We compile baseline and perform OSR immediately when the bytecode budget > interrupt hits. > > Drive-by: Clean-up deoptimizer special handling of JumpLoop by using > the newly introduced GetBaselinePCForNextExecutedBytecode instead of > GetBaselineEndPCForBytecodeOffset. > > Bug: v8:11420 > Change-Id: Ifbea264d4a83a127dd2a11e28626bf2a5e8aca59 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2784687 > Commit-Queue: Patrick Thier <pthier@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73677} Bug: v8:11420 Change-Id: I335640216dbbf9a854fc276f3df95bf5a1f9956a No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2787192Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#73680}
-
Patrick Thier authored
Add support for OSR to baseline code. We compile baseline and perform OSR immediately when the bytecode budget interrupt hits. Drive-by: Clean-up deoptimizer special handling of JumpLoop by using the newly introduced GetBaselinePCForNextExecutedBytecode instead of GetBaselineEndPCForBytecodeOffset. Bug: v8:11420 Change-Id: Ifbea264d4a83a127dd2a11e28626bf2a5e8aca59 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2784687 Commit-Queue: Patrick Thier <pthier@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#73677}
-
- 17 Feb, 2021 2 commits
-
-
Seth Brenith authored
This is a reland of cf93071c Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
-
Victor Gomes authored
Change-Id: Icdd2d4a178415d240a82378ffa575e6e6b79dca1 Bug: v8:11429 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697353Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#72805}
-
- 16 Feb, 2021 2 commits
-
-
Leszek Swirski authored
This reverts commit cf93071c. Reason for revert: Speculative revert because of Mac4 GC stress failure: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/16697/overview Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} TBR=rmcilroy@chromium.org,mythria@chromium.org,seth.brenith@microsoft.com Change-Id: I0162b9400861b90bacef27cca9aebc8ab9d74c10 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697350Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#72777}
-
Seth Brenith authored
Design doc: https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit This change adds 16 new interpreter opcodes, kStar0 through kStar15, so that we can use a single byte to represent the common operation of storing to a low-numbered register. This generally reduces the quantity of bytecode generated on web sites by 8-9%. In order to not degrade speed, a couple of other changes are required: The existing lookahead logic to check for Star after certain other bytecode handlers is updated to check for these new short Star codes instead. Furthermore, that lookahead logic is updated to contain its own copy of the dispatch jump rather than merging control flow with the lookahead-failed case, to improve branch prediction. A bunch of constants use bytecode size in bytes as a proxy for the size or complexity of a function, and are adjusted downward proportionally to the decrease in generated bytecode size. Other small drive-by fix: update generate-bytecode-expectations to emit \n instead of \r\n on Windows. Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#72773}
-