- 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}
-
- 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}
-
- 15 Jul, 2020 1 commit
-
-
Igor Sheludko authored
... this will avoid the need to pass AllocationPolicy to every method that can allocate/deallocate and allows to make deallocation method implementation stateful. The latter will also allow implementing accounting of deallocated zone memory. Adding one more field is generally fine because usually these hashmap objects are allocated on the stack or inside other rarely-allocated long-lived objects. The only exception is Scope class. The Scope objects are created very often during parsing and each of them has a VariableMap field. The Scope object size issue will be addressed in a follow-up CL. Bug: v8:10572 Change-Id: I63fbd41246cf2e568c8ba80c213d3e9caffc2c87 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2284992Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#68877}
-
- 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}
-
- 08 Dec, 2016 1 commit
-
-
leszeks authored
Wrap the liveness bitvectors from the bytecode liveness analysis with a helper class, which makes the register/accumulator bits explicit. Review-Url: https://codereview.chromium.org/2552723004 Cr-Commit-Position: refs/heads/master@{#41589}
-
- 29 Nov, 2016 3 commits
-
-
leszeks authored
Replaces the graph-based liveness analyzer in the bytecode graph builder with an initial bytecode-based liveness analysis pass, which is added to the existing loop extent analysis. Now the StateValues in the graph have their inputs initialised to optimized_out, rather than being modified after the graph is built. Review-Url: https://codereview.chromium.org/2523893003 Cr-Commit-Position: refs/heads/master@{#41355}
-
leszeks authored
Revert of [ignition/turbo] Perform liveness analysis on the bytecodes (patchset #17 id:320001 of https://codereview.chromium.org/2523893003/ ) Reason for revert: Breaks the build: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20shared/builds/14886 Original issue's description: > [ignition/turbo] Perform liveness analysis on the bytecodes > > Replaces the graph-based liveness analyzer in the bytecode graph builder > with an initial bytecode-based liveness analysis pass, which is added to > the existing loop extent analysis. > > Now the StateValues in the graph have their inputs initialised to > optimized_out, rather than being modified after the graph is built. > > Committed: https://crrev.com/1852300954c216c29cf93444430681d213e87925 > Cr-Commit-Position: refs/heads/master@{#41344} TBR=jarin@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review-Url: https://codereview.chromium.org/2541443002 Cr-Commit-Position: refs/heads/master@{#41346}
-
leszeks authored
Replaces the graph-based liveness analyzer in the bytecode graph builder with an initial bytecode-based liveness analysis pass, which is added to the existing loop extent analysis. Now the StateValues in the graph have their inputs initialised to optimized_out, rather than being modified after the graph is built. Review-Url: https://codereview.chromium.org/2523893003 Cr-Commit-Position: refs/heads/master@{#41344}
-