- 10 Feb, 2020 1 commit
-
-
Santiago Aboy Solanes authored
FunctionEntry StackChecks is one of the two cases where we generate a StackCheck bytecode. In these cases, we do stack check against the js limit (not to be confused with the real js limit). Their purpose is to be able to interrupt the running code. We can omit the FunctionEntry StackCheck by embedding its code into the InterpreterEntryTrampoline builtin. We save one bytecode per interpreted function. This change has rippling effects for optimized code, as well as the deoptimizer. Bug: v8:10149, v8:9977, v8:9960 Change-Id: I6156de48b3bc0b519dd21190a8e6214fbe96c78d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1914218Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66206}
-
- 11 Nov, 2019 1 commit
-
-
Jakob Gruber authored
The function-entry stack check should dominate all other instructions in a function. Prior to this CL it was possible to create paths not including a stack check due to SwitchOnGeneratorState: the generator-creation branch had a stack check, while generator-resume branches did not. 0 : af fb 00 01 SwitchOnGeneratorState r0, [0], [1] { 0: @22 } 4 : 27 fe fa Mov <closure>, r1 7 : 27 02 f9 Mov <this>, r2 10 : 64 0a fa 02 InvokeIntrinsic [_CreateJSGeneratorObject], r1-r2 14 : 26 fb Star r0 16 : a7 StackCheck 17 : b0 fb fb 01 00 SuspendGenerator r0, r0-r0, [0] 22 : b1 fb fb 01 ResumeGenerator r0, r0-r0 [... no stack check here ...] This CL moves the stack check to the beginning of the bytecode array, i.e. before SwitchOnGeneratorState. Bug: chromium:1020031 Change-Id: I8ba8cba99611ddbe50c76023129d926cc84b1d5e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1903440Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#64888}
-
- 08 Nov, 2018 1 commit
-
-
Jaroslav Sevcik authored
As opposed to the register. For subtle reasons, this fixes a deoptimizer bug with handling return values in lazy deopt. Since the return values can now only overwrite the accumulator, there is no danger of overwriting a captured object that might be later used (since there is no "later"). Bug: chromium:902608 Change-Id: I3a7a10bb1c7a6f4303a01d60f80680afcb7bc942 Reviewed-on: https://chromium-review.googlesource.com/c/1325901Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#57349}
-
- 17 Sep, 2018 1 commit
-
-
Creddy authored
We do not have to collect feedback for function calls in one-shot code. This CL avoids allocating CallICslots for each function call by emitting CallNoFeedback bytecodes. We save one CallICSlot (two entries in feedback vector) per function call in One-shot. Bug: v8:8072 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ic2580e5972acd5124c2e71d540985736ce797fe8 Reviewed-on: https://chromium-review.googlesource.com/1178051 Commit-Queue: Chandan Reddy <chandanreddy@google.com> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#55951}
-
- 10 Aug, 2018 1 commit
-
-
Creddy authored
No need to create allocation site for literals in oneshot code since they are executed only once. The interpreter emits a runtime call to CreateObjectLiteralWithoutAllocationSite for creating literals in oneshot code instead. Change-Id: I224b3a30f10361cfe9ff63129b36da8230c5e403 Reviewed-on: https://chromium-review.googlesource.com/1163615 Commit-Queue: Chandan Reddy <chandanreddy@google.com> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#55050}
-
- 09 Aug, 2018 1 commit
-
-
Creddy authored
This is a reland of 690bda84 Original change's description: > [Interpreter] Do not use IC slots for property load/stores in an IIFE and top-level code > > An IIFE or top-level code is executed only once hence, there is no need to collect > type feedback. We can save some memory by not using IC slots for property Loads/Stores > within a IIFE/top-level code. This CL emits Runtime Get/Set property calls instead of LdaNamedProperty > /StaNamedProperty for the property loads within a IIFE and top-level code. > > Change-Id: I3e0ce26d05d82bb3648cb9262c4e112a2c4556c9 > Reviewed-on: https://chromium-review.googlesource.com/1146579 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Chandan Reddy <chandanreddy@google.com> > Cr-Commit-Position: refs/heads/master@{#54949} Change-Id: I7b07ce86f7236d82191caaceafd31b86e5863ff5 Reviewed-on: https://chromium-review.googlesource.com/1167802Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Chandan Reddy <chandanreddy@google.com> Cr-Commit-Position: refs/heads/master@{#55017}
-
- 08 Aug, 2018 1 commit
-
-
Michael Achenbach authored
This reverts commit 690bda84. Reason for revert: Speculative revert for: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8-Blink%20Linux%2064/25372 See more at: https://github.com/v8/v8/wiki/Blink-layout-tests Original change's description: > [Interpreter] Do not use IC slots for property load/stores in an IIFE and top-level code > > An IIFE or top-level code is executed only once hence, there is no need to collect > type feedback. We can save some memory by not using IC slots for property Loads/Stores > within a IIFE/top-level code. This CL emits Runtime Get/Set property calls instead of LdaNamedProperty > /StaNamedProperty for the property loads within a IIFE and top-level code. > > Change-Id: I3e0ce26d05d82bb3648cb9262c4e112a2c4556c9 > Reviewed-on: https://chromium-review.googlesource.com/1146579 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Chandan Reddy <chandanreddy@google.com> > Cr-Commit-Position: refs/heads/master@{#54949} TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,yangguo@chromium.org,cbruni@chromium.org,leszeks@chromium.org,verwaest@chromium.org,chandanreddy@google.com Change-Id: I642164a72453189fd0fe92b69f199f958ce56bef No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/1166782Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#54955}
-
- 07 Aug, 2018 1 commit
-
-
Creddy authored
An IIFE or top-level code is executed only once hence, there is no need to collect type feedback. We can save some memory by not using IC slots for property Loads/Stores within a IIFE/top-level code. This CL emits Runtime Get/Set property calls instead of LdaNamedProperty /StaNamedProperty for the property loads within a IIFE and top-level code. Change-Id: I3e0ce26d05d82bb3648cb9262c4e112a2c4556c9 Reviewed-on: https://chromium-review.googlesource.com/1146579Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Chandan Reddy <chandanreddy@google.com> Cr-Commit-Position: refs/heads/master@{#54949}
-