- 24 Feb, 2022 1 commit
-
-
Leszek Swirski authored
Maglev is mid-tier optimising compiler designed mainly for compilation speed that can still generate good code for straightforward JS. This initial commit is an MVP for Maglev which can compile and run some very simple code, and sets up a framework that we can build upon. Design: https://docs.google.com/document/d/13CwgSL4yawxuYg3iNlM-4ZPCB8RgJya6b8H_E2F-Aek/edit# Bug: v8:7700 Change-Id: I5ae074ae099126c2c0d50864ac9b3d6fa5c9e85a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3483664Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#79247}
-
- 15 Feb, 2022 1 commit
-
-
Leszek Swirski authored
Instead of using runtime lookups of various bytecode properties (like whether they read/write the accumulator, what their operands do to registers, etc), do a switch over the bytecode itself once and dispatch to update methods that are templated on the bytecode and statically know everything about it. Change-Id: I0ae111af54277c26c7d0d67a404a2ef75f81fcf4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3455826Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#79102}
-
- 14 Feb, 2022 1 commit
-
-
Leszek Swirski authored
Previously, the accumulator was at the end of liveness bitvectors, which meant that checking for accumulator liveness required a length lookup. This CL moves it to the start of the bitvector, with registers starting at index 1 -- the assumption is that the addition of 1 to the index on register liveness access can be constant folded away. As a cleanup, replace all the custom liveness printing code with a single unified ToString. This places the accumulator at the end of the printed liveness, to avoid having to change test expectations (also, the position of the accumulator is now an implementation detail). As a similar cleanup, change StateValue node building to use the BytecodeLivenessState interface rather than the underlying bitvector. These two cleanups allow us to remove the raw bitvector accessor from liveness entirely. Change-Id: Ic2744b5e8e16b8527e6a4e8d3b4ddad7096289d9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3455144 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/main@{#79066}
-
- 11 Feb, 2022 1 commit
-
-
Leszek Swirski authored
Bytecode liveness needs a mapping from offset to liveness. This was previously a hashmap with a very weak hash (the identity function) and both inserts and lookups showed up as a non-trivial costs during compilation. Now, replace the hashmap with a simple flat array of liveness, indexed by offset, pre-sized to the size of the bytecode. This will have a lot of empty entries, but will have much better runtime performance and probably ends up not much less memory efficient as a hashmap if the hashmap has to resize inside the Zone, and is likely negligible compared to the other compilation memory overheads. Change-Id: Id21375bfcbf0d53b5ed9c41f30cdf7fde66ee699 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3455802Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#79049}
-
- 04 Feb, 2022 1 commit
-
-
Leszek Swirski authored
Return/Throw/Rethrow all unconditionally exit the bytecode, so the bytecode liveness analysis shouldn't merge their next bytecode's liveness into them. Change-Id: I62f53d16f2763e12a702b8b40b2573c264488968 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3439915 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/main@{#78951}
-
- 21 Dec, 2021 1 commit
-
-
Leszek Swirski authored
Straight-line bytecode with exactly one "next" bytecode (i.e. everything that can't affect control flow) will always have the same "out" liveness as the next bytecode's "in" liveness. For those cases, we can save a bit of time and memory by aliasing the pointers between the bytecode's out liveness and the next bytecode's in liveness, and skipping copying between them. This is done by specializing the current liveness update on whether this is the first pass (which will allocate and initialize the liveness bitvectors) or an update pass (which will revisit loops to collect liveness crossing over the back-edge, and propagate this liveness through the loop bodies). On the first pass, we can delay allocation of the out liveness until we know it needs to be union of multiple in livenesses, and on the update pass we can skip it if it is an alias. As a drive-by, tweak BitVector::CopyFrom to require copying from a vector with the same size (same as Union or Intersect), and move the only different sized vector use (in Resize) to be inline. Change-Id: Iad1b2e1b927a37ad925ef68e2a224152aaa2ba18 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3350452 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@{#78425}
-
- 16 Dec, 2021 1 commit
-
-
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}
-
- 11 Oct, 2021 1 commit
-
-
Ng Zhi An authored
Bug: v8:12244,v8:12245 Change-Id: Ic609c486fddcdb9b8171f013eb400dd74926d871 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3213142Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/main@{#77325}
-
- 24 Jun, 2021 1 commit
-
-
Peter Kasting authored
These indicate when a range-based for loop is using an index whose type (value, pointer, or reference) doesn't match what the loop actually extracts from the range. Fix by matching the actual type better. This shouldn't cause any behavior/performance change, just be slightly clearer about what's actually happening when reading the code. Bug: chromium:1223264 Change-Id: Ib8773fbbeb038609c54a52c7cd6ce5bd11fd99ba Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2983710Reviewed-by:
Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Peter Kasting <pkasting@chromium.org> Cr-Commit-Position: refs/heads/master@{#75373}
-
- 24 Feb, 2021 1 commit
-
-
Georg Neis authored
It had essentially become a synonym for BytecodeArrayAccessor. This removes the BytecodeArrayIterator class and renames BytecodeArrayAccessor to BytecodeArrayIterator. Change-Id: I79cf8574f3c8804822f90c8f921c17ca7ab85f48 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2715523 Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#73005}
-
- 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}
-
- 20 Jan, 2021 1 commit
-
-
Jakob Gruber authored
This reflects the actual contents of the type, which is an offset into the bytecode (or certain marker values). Historically, in the days of FCG the bailout id used to refer to node ids - this is why certain tracing output still calls the bailout id 'node id' and 'ast id'. These spots will be fixed in a follow-up CL. This change is mechanical: git grep -l BailoutId | while read f; do \ sed -i 's/BailoutId/BytecodeOffset/g' $f; done With a manual component of updating the DeoptimizationData method name from 'BytecodeOffset' to 'GetBytecodeOffset'. Bug: v8:11332 Change-Id: I956b947a480bf52263159c0eb1e895360bcbe6d2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639754 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72189}
-
- 15 Dec, 2020 1 commit
-
-
Ross McIlroy authored
The SerializerForBackgroundCompilation needs bytecode analysis for loop target analysis, but doesn't require the much more expensive liveness analysis. In order to move more work off the main thread, perform fast bytecode analysis without liveness analysis in SerializerForBackgroundCompilation, and then move the full bytecode analysis to the background thread in BytecodeGraphBuilder. BUG=v8:7790,v8:9684 Change-Id: I63ef80ecab8ad0c56953c72be31abc8f5a74b9c1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2593329Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#71767}
-
- 10 Jul, 2020 1 commit
-
-
Igor Sheludko authored
... by migrating old-style code MyObject* obj = new (zone) MyObject(...) to the new style MyObject* obj = zone->New<MyObject>(...) Bug: v8:10689 Change-Id: Iec2b3102bd35ad7e50b90882ade78d27999a71f2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2288866Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#68803}
-
- 20 Mar, 2020 1 commit
-
-
Santiago Aboy Solanes authored
Since now the IterationBody StackChecks are implicit within JumpLoops, we are able to eagerly deopt in them. If we do that, whenever we advance to the next bytecode we don't have to advance to the next literal bytecode, but instead "advance" in the sense of doing the JumpLoop. Adding tests that test this advancing for wide and extra wide JumpLoops. Also, marking JumpLoop as needing source positions since now it has the ability of causing an interrupt. Bug: v8:10149, v8:9960 Fixes: v8:10149 Change-Id: Ib0d9efdfb379e0dfbba7a7f67cba9262668813b0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2064226Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66809}
-
- 29 Jul, 2019 1 commit
-
-
Georg Neis authored
Change-Id: I7dbc632ea3eff419d6670519f7005382e2cadce4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1720815 Auto-Submit: Georg Neis <neis@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#62951}
-
- 26 Jul, 2019 1 commit
-
-
Georg Neis authored
... mostly by turning them into pointer arguments. After this CL, all remaining non-const reference arguments in the compiler directory are in the backend. Bug: v8:9429 Change-Id: I6a546da0fe93179e1a0b12296632591cbf209808 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719185Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#62930}
-
- 15 Jul, 2019 1 commit
-
-
Georg Neis authored
When --concurrent-inlining is on, run bytecode analysis for all relevant functions at serialization time, and store the results in the broker. Change bytecode analysis such that running it for OSR produces information that subsumes the non-OSR case. This lets us avoid doing and storing two analyses for the top-level function in case we do OSR and the function gets inlined into itself. Bug: v8:7790 Change-Id: I7d5df0b2652e6e5c758c85578e51b4f8d041b0d9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1690959 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#62711}
-
- 08 Jul, 2019 1 commit
-
-
Clemens Hammacher authored
Cpplint usually checks for non-const reference arguments. They are forbidden in the style guide, and v8 does not explicitly make an exception here. This CL re-enables that warning, and fixes all current violations by adding an explicit "NOLINT(runtime/references)" comment. In follow-up CLs, we should aim to remove as many of them as possible. TBR=mlippautz@chromium.org Bug: v8:9429 Change-Id: If7054d0b366138b731972ed5d4e304b5ac8423bb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1687891Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#62551}
-
- 19 Jun, 2019 1 commit
-
-
Jaroslav Sevcik authored
This is to allow instantiating things like bytecode array iterator for accessing both on-heap and off-heap bytecode arrays. Bug: v8:7790 Change-Id: I8dbd0884f79923d69dbc8b168d3a4a200eab14b2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1640199 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#62266}
-
- 23 May, 2019 2 commits
-
-
Yang Guo authored
NOPRESUBMIT=true TBR=mstarzinger@chromium.org Bug: v8:9247 Change-Id: I4cd6b79a1c2cba944f6f23caed59d4f1a4ee358b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624217 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#61790}
-
Yang Guo authored
TBR=bmeurer@chromium.org,leszeks@chromium.org Bug: v8:9247 Change-Id: I8d14d0192ea8c705f8274e8e61a162531826edb6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624220Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#61769}
-
- 29 Apr, 2019 1 commit
-
-
Georg Neis authored
Also const-ify and refactor a few things in BytecodeAnalysis. Change-Id: Ibd261bb67d8c035b1f818e9114d09db08737000d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587384 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#61088}
-
- 22 Jan, 2019 1 commit
-
-
Peter Marshall authored
Everything was including log.h through heap-inl.h, so remove that include by moving the one user into heap.cc, and then fix all the include errors. This reduces the log.h include ball from ~550 to ~100. Change-Id: I6d09bc2f365b48645fcfdc695a68ea12539a745d Reviewed-on: https://chromium-review.googlesource.com/c/1424198 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#58981}
-
- 18 Sep, 2018 1 commit
-
-
Florian Sattler authored
Fixing clang-tidy warning. Bug: v8:8015 Change-Id: I33858c6f6bb577f39f697a1d3094990a57044fca Reviewed-on: https://chromium-review.googlesource.com/1228065 Commit-Queue: Florian Sattler <sattlerf@google.com> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#55990}
-
- 22 Mar, 2018 1 commit
-
-
Leszek Swirski authored
SuspendGenerator needs the accumulator to be live so that it can return it. Bug: chromium:806723 Change-Id: Iaa88fce96c36876e3e4256324ca650d475480c10 Reviewed-on: https://chromium-review.googlesource.com/975404Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#52147}
-
- 27 Feb, 2018 1 commit
-
-
Michael Starzinger authored
This changes the encoding of the {HandlerTable} from an array of Smi values to a byte array. It allows embedding of said array into the instruction stream of {Code} objects (similar to how safepoint tables work). For interpreted bytecode the table is attached as a {ByteArray} to the bytecode. The advantage of this approach is a more compact encoding and also the ability to move such tables easily off the GC'ed heap if needed (as is done for WebAssembly code for example). R=jarin@chromium.org Change-Id: I3320415dff69b3d1053825bda0d667a28232bf6d Reviewed-on: https://chromium-review.googlesource.com/934642 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#51589}
-
- 23 Jan, 2018 1 commit
-
-
Leszek Swirski authored
Currently, yields and awaits inside loops compile to bytecode which switches to the top of the loop header, and switch again once inside the loop. This is to make loops reducible. This replaces this switching logic with a single switch bytecode that directly jumps to the bytecode being resumed. Among other things, this allows us to no longer maintain the generator state after the switch at the top of the function, and avoid having to track loop suspend counts. TurboFan still needs to have reducible loops, so we now insert loop header switches during bytecode graph building, for suspends that are discovered to be inside loops during bytecode analysis. We do, however, do some environment magic across loop headers since we know that we will continue switching if and only if we reached that loop header via a generator resume. This allows us to generate fewer phis and tighten liveness. Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385 Reviewed-on: https://chromium-review.googlesource.com/866734 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#50804}
-
- 22 Jan, 2018 1 commit
-
-
Leszek Swirski authored
Suspend points (inside generators and async functions) have slightly funky semantics when it comes to liveness, as they save and restore a chunk of the register file as-is. In particular, this means that granular liveness information is lost, as it is assumed that all registers in that chunk of the register file are live in a suspend. Rather than marking that entire chunk of register as live/dead in suspend/restore, we can instead pattern-match the set of bytecodes in a suspend point, and propagate liveness across them. This tightens liveness estimates, and could be used to optimize which values TurboFan actually saves when suspending. Bug: chromium:798137 Change-Id: I5840cdbfc2c6edb1d3a48cf025f52615b629cdfc Reviewed-on: https://chromium-review.googlesource.com/848895 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#50757}
-
- 05 Sep, 2017 1 commit
-
-
Jakob Kummerow authored
AFAICT this doesn't currently change observable behavior, but should be fixed nonetheless. Change-Id: I1dce90ae5bcad39d7d54dddd2559bd7f7ccbb095 Reviewed-on: https://chromium-review.googlesource.com/648354Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#47835}
-
- 31 Aug, 2017 1 commit
-
-
Michael Starzinger authored
R=leszeks@chromium.org Change-Id: Iae67b6b81459304192c81b1367a11fba076c7512 Reviewed-on: https://chromium-review.googlesource.com/645630Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47741}
-
- 25 Aug, 2017 1 commit
-
-
Ross McIlroy authored
For wide bytecodes, save the bytecode offset as the offset of the prefix bytecode, rather than the bytecode itself. This means that any code that reads the bytecode can explicitly know the width of the bytecode at the offset without having to iterate through the complete bytecode array. Also simplifies some code in the bytecode analysis that had to work around the previous approach. BUG=chromium:753705 Change-Id: I8a42e7cfff27791e39f3452e2b9e52c0608d28cb Reviewed-on: https://chromium-review.googlesource.com/634003 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47599}
-
- 17 Aug, 2017 1 commit
-
-
Leszek Swirski authored
The accumulator should never be alive when jumping back to a loop header, or jumping out of a loop. This means that as far as far as TurboFan is concerned, we never need to create Phis or LoopExitValues for the accumulator, as its value should not escape the loop. For safety, this also augments the IsLivenessValid DCHECK in the liveness analysis to check that the accumulator is not live in these cases, and amends the bytecode analysis tests to kill the accumulator where necessary to ensure this. As a drive-by, added some comments to the more complex bytecode analysis tests, since figuring out what they were for and how to fix them took a non-trivial amount of time. Change-Id: Idecf76a36681d724134c59768650c23cc6b0e9ef Reviewed-on: https://chromium-review.googlesource.com/615168 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#47388}
-
- 16 Aug, 2017 1 commit
-
-
Leszek Swirski authored
Now that OSR is done during graph building, we no longer have to special-case OSR loops in the loop assignment analysis, as we no longer have the restriction that registers are 'assigned' an OSRValue inside the loop. Bug: v8:6518 Change-Id: Ib4fa139091d77efa16246ddc6e63a10cbb877ee4 Reviewed-on: https://chromium-review.googlesource.com/615167Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#47367}
-
- 02 Aug, 2017 1 commit
-
-
Julien Brianceau authored
Bug: chromium:750830 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Icab7b5a1c469d5e77d04df8bfca8319784e92af4 Reviewed-on: https://chromium-review.googlesource.com/595655 Commit-Queue: Julien Brianceau <jbriance@cisco.com> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#47072}
-
- 02 Jun, 2017 1 commit
-
-
jarin authored
This is a first step towards reducing the number of stores/loads when suspending/resuming a generator. Unfortunately, even for an empty generator, we still use 8 register for various things (try-finally, copies of generator object, parser-introduced temporaries). I will try to get rid of these in separate CLs. Changes: - SuspendGenerator bytecode now takes register list to save. - ResumeGenerator was split into two bytecodes: * Resume generator reads the state out and marks the generator as 'executing'. * RestoreGeneratorRegisters reloads the registers from the generator. + this required adding support for output register list. - Introduced generator_object_ register in the bytecode generator. * in subsequent CLs, I will make better use of it, the goal is to get rid if the .generator_object local variable. - Taught register optimizer to flush unassigned registers. BUG=v8:6379 Review-Url: https://codereview.chromium.org/2894293003 Cr-Commit-Position: refs/heads/master@{#45675}
-
- 15 May, 2017 1 commit
-
-
Leszek Swirski authored
Introduce a new SwitchSmiTable bytecode for generators, which does a table lookup for the accumulator value in a jump table stored in the constant array pool. This removes the if-else chains at resumable function/loop headers. As a drive-by, add a scoped environment saving struct to the bytecode graph builder. Bug: v8:6351 Bug: v8:6366 Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0 Reviewed-on: https://chromium-review.googlesource.com/500271 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45314}
-
- 26 Apr, 2017 1 commit
-
-
Leszek Swirski authored
Instead of calculating the OSR entry point both in the bytecode analysis and in the bytecode graph builder, calculate it once in the analysis and use that calculation in the graph builder. Old TODO from https://codereview.chromium.org/2558093005. Change-Id: I071bc622beb55dc5eddaee25ef28e21fc4b477f0 Reviewed-on: https://chromium-review.googlesource.com/485899 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#44888}
-