-
Clemens Backes authored
We currently have a BitVector implementation which is used a lot by the two (mid-tier and top-tier) register allocators. Their size is the number of virtual registers or the number of blocks in the function. If one of those numbers gets huge, the BitVector does not perform well any more, and it consumes huge amounts of memory (we see up to several GBs for huge Wasm functions). This CL introduces a SparseBitVector implementation with a compatible interface, meant to replace the BitVector implementation. Usages will be introduced in follow-up CLs, first for the mid-tier allocator, then top-tier. This will allow us to assess performance changes better, and revert individual usages. R=mslekova@chromium.org Bug: chromium:1313379, v8:12780 Change-Id: I804311e0c188526961f70e88a43dd1ea26497cda Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3634780 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/main@{#80546}
5696b526