- 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}
-