- 17 Feb, 2021 1 commit
-
-
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}
-
- 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}
-
- 11 Feb, 2021 1 commit
-
-
Seth Brenith authored
In https://chromium-review.googlesource.com/c/v8/v8/+/2641180 , we are discussing renaming AccumulatorUse. To avoid polluting that change with a large mechanical find&replace, I've created a separate change for the renaming. Change-Id: Ibc7e438f9e719571c9237e7e08ba86562a3c679f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2684923Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#72679}
-
- 28 Jan, 2021 1 commit
-
-
Toon Verwaest authored
This very slightly improves the performance of bytecode array visitors. Change-Id: I39df381a26106b5576df74c8c204279b224a92af Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2653227 Auto-Submit: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#72387}
-
- 08 Jan, 2021 1 commit
-
-
Seth Brenith authored
I made some temporary changes in BytecodeArrayWriter to log counts of how often each pair of bytecodes is adjacent. In data I collected on a Facebook page with those changes enabled, I noticed that the following bytecodes were commonly followed by Star, but do not appear in IsStarLookahead. LdaImmutableCurrentContextSlot: 4.4% of all instructions, 66% chance to be followed by Star CreateClosure: 3.9% of all instructions, 57% chance to be followed by Star LdaImmutableContextSlot: 1.7% of all instructions, 95% chance to be followed by Star CreateObjectLiteral: 1.4% of all instructions, 92% chance to be followed by Star CreateArrayLiteral: 1.4% of all instructions, 99% chance to be followed by Star ThrowReferenceErrorIfHole: 0.7% of all instructions, 100% chance to be followed by Star GetTemplateObject: 0.6% of all instructions, 100% chance to be followed by Star CreateEmptyArrayLiteral: 0.4% of all instructions, 87% chance to be followed by Star CreateEmptyObjectLiteral: 0.2% of all instructions, 79% chance to be followed by Star I cross-referenced this list with data from google.com and youtube.com (the top two sites according to Alexa), and found that CreateClosure and CreateEmpty*Literal are not likely followed by Star on those sites. Without those three, I suggest that the following bytecode handlers would likely benefit from Star lookahead: LdaImmutableCurrentContextSlot LdaImmutableContextSlot CreateObjectLiteral CreateArrayLiteral ThrowReferenceErrorIfHole GetTemplateObject I also ran Octane with --noopt and got the following results. Name Median change (95% CI) U test result ----------------- ------------------------ ------------------- Richards +1.02% to +3.28% improved p=1.8e-05 DeltaBlue -1.47% to +0.12% regressed p=0.05 Crypto -1.11% to +0.93% inconclusive RayTrace -1.10% to +0.48% inconclusive EarleyBoyer -0.25% to +1.29% inconclusive RegExp -1.46% to +0.08% inconclusive Splay -1.10% to +0.03% inconclusive SplayLatency +0.13% to +0.92% improved p=5.8e-05 NavierStokes -0.22% to +1.24% inconclusive PdfJS -0.69% to +1.04% inconclusive Mandreel -0.66% to +0.66% inconclusive MandreelLatency +0.32% to +1.77% improved p=0.00024 Gameboy -1.13% to +0.38% inconclusive CodeLoad -0.27% to +0.43% inconclusive Box2D -0.53% to +0.82% inconclusive zlib -0.19% to +0.19% inconclusive Typescript -0.23% to +0.59% inconclusive Score (version 9) -0.18% to +0.68% inconclusive I'm somewhat puzzled by the DeltaBlue regression, since DeltaBlue agrees that all of the selected bytecodes are likely to precede Star, but overall I think this change is more benefit than harm. Change-Id: Ib9b4033f3cda273e99c9f0252d0055e203921916 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615946Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#71987}
-
- 06 Sep, 2019 1 commit
-
-
Swapnil Gaikwad authored
This is a reland of 8b89a7c3 Reland after disabling the test getting deadlocked with '--gc_stress' flag. The CL was reverted because of the 'wasm/grow-shared-memory' test from the mjsunit test suite deadlocked for the 'gc_stress' variant. This is the known issue (v8:9221) and the deadlocking test is now disabled ( https://chromium.googlesource.com/v8/v8.git/+/1c8981e3f4729b7a8220a8823e0a0d45f2a4b788). Original change's description: > Update GetIterator bytecode to load and call object[Symbol.iterator] > > The functionality of the GetIterator bytecode introduced previously is > now extended from loading the @@iterator property to calling the property > as well. This change basically absorbs the functionality of additional > two bytecodes - Star, CallProperty0 in the GetIterator bytecode. > Importantly, this change handles the cases of eager and lazy deoptimization > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and > eager deopt of the CallProperty0 bytecode, using the continuation builtins. > This mechanism can work as a template for the future bytecode that require > handling such inter-bytecode deopt scenario. The tests evaluating the eager > and lazy deopt scenarios are also included. > > Bug: v8:9489 > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313 > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63528} Bug: v8:9489,v8:9221 Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Cr-Commit-Position: refs/heads/master@{#63599}
-
- 03 Sep, 2019 2 commits
-
-
Francis McCabe authored
This reverts commit 8b89a7c3. Reason for revert: GC Stress tests timing out. See https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/24272 Original change's description: > Update GetIterator bytecode to load and call object[Symbol.iterator] > > The functionality of the GetIterator bytecode introduced previously is > now extended from loading the @@iterator property to calling the property > as well. This change basically absorbs the functionality of additional > two bytecodes - Star, CallProperty0 in the GetIterator bytecode. > Importantly, this change handles the cases of eager and lazy deoptimization > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and > eager deopt of the CallProperty0 bytecode, using the continuation builtins. > This mechanism can work as a template for the future bytecode that require > handling such inter-bytecode deopt scenario. The tests evaluating the eager > and lazy deopt scenarios are also included. > > Bug: v8:9489 > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313 > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63528} TBR=rmcilroy@chromium.org,neis@chromium.org,leszeks@chromium.org,tebbi@chromium.org,swapnilgaikwad@google.com Change-Id: I9ae475f71275f71f1b9e60b8bf0578e21ce2704b No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9489 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1783736Reviewed-by:
Francis McCabe <fgm@chromium.org> Commit-Queue: Francis McCabe <fgm@chromium.org> Cr-Commit-Position: refs/heads/master@{#63536}
-
Swapnil Gaikwad authored
The functionality of the GetIterator bytecode introduced previously is now extended from loading the @@iterator property to calling the property as well. This change basically absorbs the functionality of additional two bytecodes - Star, CallProperty0 in the GetIterator bytecode. Importantly, this change handles the cases of eager and lazy deoptimization in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and eager deopt of the CallProperty0 bytecode, using the continuation builtins. This mechanism can work as a template for the future bytecode that require handling such inter-bytecode deopt scenario. The tests evaluating the eager and lazy deopt scenarios are also included. Bug: v8:9489 Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313 Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#63528}
-
- 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 Sep, 2018 1 commit
-
-
Dan Elphick authored
Previously the builtins table had a value for every single OperandScale/Bytecode combination regardless of whether it was valid. This change makes it so that only valid bytecode handlers are stored in the builtins table. This prevents placeholders being serialized into the snapshot (and embedded into the binary) saving 9KB in CODE_SPACE/OLD_SPACE and 2.5KB in the embedded data as well as 66 entries in the builtins table. To do this, it generates a new header file bytecodes-builtins-list.h which is created from the BYTECODE_LIST and OPERAND_SCALE_LIST macros. Since list macros cannot be used to conditionally generate elements in the C-preprocessor, this is done by generator executable, compiled from interpreter/generate-flat-headers.cc. Additionally the generator creates the flat bytecode list so that it is transposed from the previous result, i.e. the results are grouped by bytecode and then operand scale rather than operand scale then bytecode. This should give better locality for commonly used bytecodes and may allow less commonly used ExtraWide bytecodes to never be mapped into memory at all. The cost to storing the handlers densely is that looking up a handler now requires a binary search through the builtins table, but this should only happen during debugging. It is also fixable at least for non-wide handlers and could be improved for wide ones if the need arises. Bug: v8:8068 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: Iaad22a952e2858f508030c5ddc082f91bf59f667 Reviewed-on: https://chromium-review.googlesource.com/1209304 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#55757}
-
- 26 Jan, 2018 1 commit
-
-
Ross McIlroy authored
Refactors bytecode register access to avoid having to deal with register indexes directly. - Changes Load/StoreRegister to Load/StoreRegisterAtOperandIndex - Adds RegisterList abstraction for dealin with lists of registers - Adds helpers for Loading / Storing register pairs / triples. Change-Id: I34427e4bd7314dce0230572212580d6a93ccc2d4 Reviewed-on: https://chromium-review.googlesource.com/887062Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#50899}
-
- 25 Aug, 2017 1 commit
-
-
Ross McIlroy authored
This change adapts the Call bytecode handlers such that they don't require a stack frame. It does this by modifying the call bytecode handler to tail-call the Call or InterpreterPushArgsAndCall builtins. As a result, the callee function will return to the InterpreterEntryTrampoline when it returns (since this is the return address on the interpreter frame), which is adapted to dispatch to the next bytecode handler. The return bytecode handler is modified to tail-call a new InterpreterExitTramoline instead of returning to the InterpreterEntryTrampoline. Overall this significanlty reduces the amount of stack space required for interpreter frames, increasing the maximum depth of recursive calls from around 6000 to around 12,500 on x64. BUG=chromium:753705 Change-Id: I23328e4cef878df3aca4db763b47d72a2cce664c Reviewed-on: https://chromium-review.googlesource.com/634364 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#47617}
-
- 26 Jun, 2017 1 commit
-
-
hans authored
This is towards closing the perf gap between the MSVC build (which uses link- time optimization) and Clang (where LTO isn't ready on Windows yet). We did a study (see bug) to see which non-inlined functions are hit a lot during render start-up, and which would be inlined during LTO. This should benefit performance in all builds which currently don't use LTO (Android, Linux, Mac) as well as the Win/Clang build. The binary size of chrome_child.dll increases by 2KB with this. BUG=chromium:728324 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.mac:mac_chromium_compile_dbg_ng Review-Url: https://codereview.chromium.org/2950993002 Cr-Commit-Position: refs/heads/master@{#46229}
-
- 25 Jun, 2017 1 commit
-
-
machenbach authored
Revert of Make some functions that are hit during renderer startup available for inlining (patchset #3 id:40001 of https://codereview.chromium.org/2950993002/ ) Reason for revert: Blocks roll: https://codereview.chromium.org/2954833002/ E.g.: https://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_compile_dbg_ng/builds/449680 https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_compile_dbg_ng/builds/324953 Please include those chromium trybots on reland. Maybe missing symbol export? Original issue's description: > Make some functions that are hit during renderer startup available for inlining > > This is towards closing the perf gap between the MSVC build (which uses link- > time optimization) and Clang (where LTO isn't ready on Windows yet). We did > a study (see bug) to see which non-inlined functions are hit a lot during render > start-up, and which would be inlined during LTO. This should benefit performance > in all builds which currently don't use LTO (Android, Linux, Mac) as well as > the Win/Clang build. > > The binary size of chrome_child.dll increases by 2KB with this. > > BUG=chromium:728324 > > Review-Url: https://codereview.chromium.org/2950993002 > Cr-Commit-Position: refs/heads/master@{#46191} > Committed: https://chromium.googlesource.com/v8/v8/+/d00d52be1fce9c1bf5558c8b26bf984efd09e65b TBR=jochen@chromium.org,mstarzinger@chromium.org,rmcilroy@chromium.org,vogelheim@chromium.org,marja@chromium.org,mlippautz@chromium.org,thakis@chromium.org,hans@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=chromium:728324 NOTRY=true NOPRESUBMIT=true Review-Url: https://codereview.chromium.org/2955793002 Cr-Commit-Position: refs/heads/master@{#46195}
-
- 23 Jun, 2017 1 commit
-
-
hans authored
This is towards closing the perf gap between the MSVC build (which uses link- time optimization) and Clang (where LTO isn't ready on Windows yet). We did a study (see bug) to see which non-inlined functions are hit a lot during render start-up, and which would be inlined during LTO. This should benefit performance in all builds which currently don't use LTO (Android, Linux, Mac) as well as the Win/Clang build. The binary size of chrome_child.dll increases by 2KB with this. BUG=chromium:728324 Review-Url: https://codereview.chromium.org/2950993002 Cr-Commit-Position: refs/heads/master@{#46191}
-
- 22 May, 2017 1 commit
-
-
Wiktor Garbacz authored
Change-Id: I20ed35a7fb5104a9cc66bb54fa8966589c43d7f9 Reviewed-on: https://chromium-review.googlesource.com/507287Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Daniel Clifford <danno@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Jochen Eisinger <jochen@chromium.org> Commit-Queue: Wiktor Garbacz <wiktorg@google.com> Cr-Commit-Position: refs/heads/master@{#45458}
-
- 11 Apr, 2017 2 commits
-
-
Leszek Swirski authored
Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Reland of https://chromium-review.googlesource.com/c/463287 after fixing tests in https://codereview.chromium.org/2813873002. Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5 Reviewed-on: https://chromium-review.googlesource.com/474752Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44582}
-
Michael Achenbach authored
This reverts commit 751e8935. Reason for revert: Breaks layout tests: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/14885 See: https://github.com/v8/v8/wiki/Blink-layout-tests Original change's description: > [ignition] Add call bytecodes for undefined receiver > > Adds a collection of call bytecodes which have an implicit undefined > receiver argument, for cases such as global calls where we know that the > receiver has to be undefined. This way we can skip an LdaUndefined, > decrease bytecode register pressure, and set a more accurate > ConvertReceiverMode on the interpreter and TurboFan call. > > As a side effect, the "normal" Call bytecode now becomes a rare case > (only with calls and super property calls), so we get rid of its 0-2 > argument special cases and modify CallProperty[N] to use the > NotNullOrUndefined ConvertReceiverMode. > > Change-Id: I9374a32fefd66fc0251b5193bae7a6b7dc31eefc > Reviewed-on: https://chromium-review.googlesource.com/463287 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#44530} TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org,v8-reviews@googlegroups.com,v8-mips-ports@googlegroups.com,v8-ppc-ports@googlegroups.com,v8-x87-ports@googlegroups.com,bmeurer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Change-Id: I7629dec609d0ec938ce7105d6c1c74884e5f9272 Reviewed-on: https://chromium-review.googlesource.com/474744 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#44548}
-
- 10 Apr, 2017 1 commit
-
-
Leszek Swirski authored
Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Change-Id: I9374a32fefd66fc0251b5193bae7a6b7dc31eefc Reviewed-on: https://chromium-review.googlesource.com/463287 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#44530}
-
- 16 Feb, 2017 1 commit
-
-
Daniel Clifford authored
Before this patch, the registers needed for bytecode dispatch in interpreter handlers were inconsistently stored in the interpreter frame and/or kept in values that remained live across calls. After this patch, these registers are explicitly reloaded after calls, making it possible to elide the spills of those registers before the call in many cases. Some highlights from the CL: * Added methods to the CSA and InterpreterAssembler to efficiently store and load Smis values and Smi interpreter registers on x64 without explicit tagging/untagging. * Created Variables for all of the interpreter-internal values that need to be reloaded before bytecode dispatch at the end of an interpreter handler. * The bytecode offset can be written out early in a handler by marking it has having a call along it's critical path. By moving this early in a handler, it becomes possible to use memory operands for pushes used to marshall parameters when making calls. Change-Id: Icf8d7798789f88a4489e06a7092616bbbb881577 Reviewed-on: https://chromium-review.googlesource.com/442566 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#43260}
-
- 01 Feb, 2017 1 commit
-
-
petermarshall authored
Rename to Construct and ConstructWithSpread, to match the names of the JSOperators used. Unfortunately, I can't find a way for auto-formatting to stay happy unless we change the indentation for the whole BYTECODE_LIST macro. Review-Url: https://codereview.chromium.org/2663963003 Cr-Commit-Position: refs/heads/master@{#42840}
-
- 10 Nov, 2016 1 commit
-
-
rmcilroy authored
We seem to get some small wins from avoiding the Ldr bytecodes, probably due to reduced icache pressure since there are less bytecode handlers. Replace the Ldr bytecodes with Star lookahead inlined into the Lda versions. Also fixes IsAccumulatorLoadWithoutEffects to include LdaContextSlot and LdaCurrentContextSlot BUG=v8:4280 Review-Url: https://codereview.chromium.org/2489513005 Cr-Commit-Position: refs/heads/master@{#40883}
-
- 09 Nov, 2016 1 commit
-
-
rmcilroy authored
The Ldr[Named/Keyed]Property bytecodes are problematic for the deoptimizer when inlining accessors in TurboFan. Remove them and replace with a Star lookahead in the bytecode handlers for Lda[Named/Keyed]Property. BUG=v8:4280 Review-Url: https://codereview.chromium.org/2485383002 Cr-Commit-Position: refs/heads/master@{#40860}
-
- 27 Oct, 2016 1 commit
-
-
leszeks authored
This is a new bytecode which behaves (for now) exactly like Call, except that in turbofan graph building we can set the ConvertReceiverMode to NotNullOrUndefined. I observe a 1% improvement on Box2D, I'd expect a similar improvement on other OOP heavy code. Review-Url: https://codereview.chromium.org/2450243002 Cr-Commit-Position: refs/heads/master@{#40610}
-
- 22 Sep, 2016 2 commits
-
-
rmcilroy authored
This CL optimizes the code in BytecodeArrayBuilder and BytecodeArrayWriter by making the following main changes: - Move operand scale calculation out of BytecodeArrayWriter to the BytecodeNode constructor, where the decision on which operands are scalable can generally be statically decided by the compiler. - Move the maximum register calculation out of BytecodeArrayWriter and into BytecodeRegisterOptimizer (which is the only place outside BytecodeGenerator which updates which registers are used). This avoids the BytecodeArrayWriter needing to know the operand types of a node as it writes it. - Modify EmitBytecodes to use individual push_backs rather than building a buffer and calling insert, since this turns out to be faster. - Initialize BytecodeArrayWriter's bytecode vector by reserving 512 bytes, - Make common functions in Bytecodes constexpr so that they can be statically calculated by the compiler. - Move common functions and constructors in Bytecodes and BytecodeNode to the header so that they can be inlined. - Change large static switch statements in Bytecodes to const array lookups, and move to the header to allow inlining. I also took the opportunity to remove a number of unused helper functions, and rework some others for consistency. This reduces the percentage of time spent in making BytecodeArrays in CodeLoad from ~15% to ~11% according to perf. The CoadLoad score increase by around 2%. BUG=v8:4280 Committed: https://crrev.com/b11a8b4d41bf09d6b3d6cf214fe3fb61faf01a64 Review-Url: https://codereview.chromium.org/2351763002 Cr-Original-Commit-Position: refs/heads/master@{#39599} Cr-Commit-Position: refs/heads/master@{#39637}
-
hablich authored
Revert of [Interpreter] Optimize BytecodeArrayBuilder and BytecodeArrayWriter. (patchset #6 id:200001 of https://codereview.chromium.org/2351763002/ ) Reason for revert: Prime suspect for roll blocker: https://codereview.chromium.org/2362503002/ Original issue's description: > [Interpreter] Optimize BytecodeArrayBuilder and BytecodeArrayWriter. > > This CL optimizes the code in BytecodeArrayBuilder and > BytecodeArrayWriter by making the following main changes: > > - Move operand scale calculation out of BytecodeArrayWriter to the > BytecodeNode constructor, where the decision on which operands are > scalable can generally be statically decided by the compiler. > - Move the maximum register calculation out of BytecodeArrayWriter > and into BytecodeRegisterOptimizer (which is the only place outside > BytecodeGenerator which updates which registers are used). This > avoids the BytecodeArrayWriter needing to know the operand types > of a node as it writes it. > - Modify EmitBytecodes to use individual push_backs rather than > building a buffer and calling insert, since this turns out to be faster. > - Initialize BytecodeArrayWriter's bytecode vector by reserving 512 > bytes, > - Make common functions in Bytecodes constexpr so that they > can be statically calculated by the compiler. > - Move common functions and constructors in Bytecodes and > BytecodeNode to the header so that they can be inlined. > - Change large static switch statements in Bytecodes to const array > lookups, and move to the header to allow inlining. > > I also took the opportunity to remove a number of unused helper > functions, and rework some others for consistency. > > This reduces the percentage of time spent in making BytecodeArrays > in CodeLoad from ~15% to ~11% according to perf. The > CoadLoad score increase by around 2%. > > BUG=v8:4280 > > Committed: https://crrev.com/b11a8b4d41bf09d6b3d6cf214fe3fb61faf01a64 > Cr-Commit-Position: refs/heads/master@{#39599} TBR=mythria@chromium.org,leszeks@chromium.org,rmcilroy@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4280 Review-Url: https://codereview.chromium.org/2360193003 Cr-Commit-Position: refs/heads/master@{#39612}
-
- 21 Sep, 2016 1 commit
-
-
rmcilroy authored
This CL optimizes the code in BytecodeArrayBuilder and BytecodeArrayWriter by making the following main changes: - Move operand scale calculation out of BytecodeArrayWriter to the BytecodeNode constructor, where the decision on which operands are scalable can generally be statically decided by the compiler. - Move the maximum register calculation out of BytecodeArrayWriter and into BytecodeRegisterOptimizer (which is the only place outside BytecodeGenerator which updates which registers are used). This avoids the BytecodeArrayWriter needing to know the operand types of a node as it writes it. - Modify EmitBytecodes to use individual push_backs rather than building a buffer and calling insert, since this turns out to be faster. - Initialize BytecodeArrayWriter's bytecode vector by reserving 512 bytes, - Make common functions in Bytecodes constexpr so that they can be statically calculated by the compiler. - Move common functions and constructors in Bytecodes and BytecodeNode to the header so that they can be inlined. - Change large static switch statements in Bytecodes to const array lookups, and move to the header to allow inlining. I also took the opportunity to remove a number of unused helper functions, and rework some others for consistency. This reduces the percentage of time spent in making BytecodeArrays in CodeLoad from ~15% to ~11% according to perf. The CoadLoad score increase by around 2%. BUG=v8:4280 Review-Url: https://codereview.chromium.org/2351763002 Cr-Commit-Position: refs/heads/master@{#39599}
-
- 20 Sep, 2016 1 commit
-
-
rmcilroy authored
BUG=chromium:642111 Review-Url: https://codereview.chromium.org/2358523003 Cr-Commit-Position: refs/heads/master@{#39541}
-
- 13 Sep, 2016 1 commit
-
-
mstarzinger authored
This introduces a new {JumpLoop} bytecode to combine the OSR polling mechanism modeled by {OsrPoll} with the actual {Jump} performing the backwards branch. This reduces the overall size and also avoids one additional dispatch. It also makes sure that OSR polling is only done within real loops. R=rmcilroy@chromium.org BUG=v8:4764 Review-Url: https://codereview.chromium.org/2331033002 Cr-Commit-Position: refs/heads/master@{#39384}
-
- 06 Sep, 2016 1 commit
-
-
rmcilroy authored
BUG=chromium:642111 Review-Url: https://codereview.chromium.org/2313763002 Cr-Commit-Position: refs/heads/master@{#39197}
-
- 29 Aug, 2016 1 commit
-
-
bmeurer authored
These JavaScript operators were special hacks to ensure that we always operate on Smis for the magic for-in index variable, but this never really worked in the OSR case, because the OsrValue for the index variable didn't have the proper information (that we have for the JSForInPrepare in the non-OSR case). Now that we have loop induction variable analysis and binary operation hints, we can just use JSLessThan and JSAdd instead with appropriate Smi hints, which handle the OSR case by inserting Smi checks (that are always true). Thanks to OSR deconstruction and loop peeling these Smi checks will be hoisted so they don't hurt the OSR case too much. Drive-by-change: Rename the ForInDone bytecode to ForInContinue, since we have to lower it to JSLessThan to get the loop induction variable goodness. R=epertoso@chromium.org BUG=v8:5267 Review-Url: https://codereview.chromium.org/2289613002 Cr-Commit-Position: refs/heads/master@{#38968}
-
- 25 Jul, 2016 1 commit
-
-
klaasb authored
ToName was always generated with a subsequent Star, fuse them. Requires a few changes in the peephole optimizer as ToName cannot be elided as easily, but must be replaced by Star. BUG=v8:4280 LOG=n Review-Url: https://codereview.chromium.org/2169813002 Cr-Commit-Position: refs/heads/master@{#38019}
-
- 20 Jul, 2016 1 commit
-
-
klaasb authored
For some bytecodes it is beneficial to always look for a Star bytecode when dispatching to the next and inline perform it without dispatching to the Star handler. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/2142273003 Cr-Commit-Position: refs/heads/master@{#37904}
-
- 19 Jul, 2016 1 commit
-
-
oth authored
Original issue's description: > [interpeter] Move to table based peephole optimizer. > > Introduces a lookup table for peephole optimizations. > > Fixes some tests using BytecodePeepholeOptimizer::Write() that should > have been update to use BytecodePeepholeOptimizer::WriteJump(). > > BUG=v8:4280 > LOG=N > > Committed: https://crrev.com/f4234422b93b21a286b0f31799009bcbe8b90b9e > Cr-Commit-Position: refs/heads/master@{#37819} BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/2164583002 Cr-Commit-Position: refs/heads/master@{#37866}
-
- 18 Jul, 2016 2 commits
-
-
oth authored
Revert of [interpeter] Move to table based peephole optimizer. (patchset #38 id:730001 of https://codereview.chromium.org/2118183002/ ) Reason for revert: Break MIPS port. Original issue's description: > [interpeter] Move to table based peephole optimizer. > > Introduces a lookup table for peephole optimizations. > > Fixes some tests using BytecodePeepholeOptimizer::Write() that should > have been update to use BytecodePeepholeOptimizer::WriteJump(). > > BUG=v8:4280 > LOG=N > > Committed: https://crrev.com/f4234422b93b21a286b0f31799009bcbe8b90b9e > Cr-Commit-Position: refs/heads/master@{#37819} TBR=rmcilroy@chromium.org,machenbach@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4280 Review-Url: https://codereview.chromium.org/2161563002 Cr-Commit-Position: refs/heads/master@{#37821}
-
oth authored
Introduces a lookup table for peephole optimizations. Fixes some tests using BytecodePeepholeOptimizer::Write() that should have been update to use BytecodePeepholeOptimizer::WriteJump(). BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/2118183002 Cr-Commit-Position: refs/heads/master@{#37819}
-
- 15 Jul, 2016 1 commit
-
-
oth authored
> Original issue's description: > [interpreter] Reduce dependencies in bytecodes.{h,cc} > > This CL reduces the number of dependencies bytecodes.{h,cc} to facilitate > generating the bytecode peephole optimizer table during build. Specifically, > it avoids depending on v8_base. > > BUG=v8:4280 > LOG=N > > Committed: https://crrev.com/4edebb1cd870ae6c1359ad54f83e618e185883b1 > Cr-Commit-Position: refs/heads/master@{#37715} BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/2149093002 Cr-Commit-Position: refs/heads/master@{#37794}
-
- 14 Jul, 2016 1 commit
-
-
machenbach authored
Revert of [interpreter] Reduce dependencies in bytecodes.{h,cc} (patchset #8 id:140001 of https://codereview.chromium.org/2135273002/ ) Reason for revert: Breaks the roll, possibly win gn: https://codereview.chromium.org/2148863002/ Original issue's description: > [interpreter] Reduce dependencies in bytecodes.{h,cc} > > This CL reduces the number of dependencies bytecodes.{h,cc} to facilitate > generating the bytecode peephole optimizer table during build. Specifically, > it avoids depending on v8_base. > > BUG=v8:4280 > LOG=N > > Committed: https://crrev.com/4edebb1cd870ae6c1359ad54f83e618e185883b1 > Cr-Commit-Position: refs/heads/master@{#37715} TBR=mstarzinger@chromium.org,rmcilroy@chromium.org,oth@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4280 Review-Url: https://codereview.chromium.org/2151693003 Cr-Commit-Position: refs/heads/master@{#37743}
-
- 13 Jul, 2016 1 commit
-
-
oth authored
This CL reduces the number of dependencies bytecodes.{h,cc} to facilitate generating the bytecode peephole optimizer table during build. Specifically, it avoids depending on v8_base. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/2135273002 Cr-Commit-Position: refs/heads/master@{#37715}
-