Speed up `SparseBitMatrix` use in `RegionValues`.
In practice, these matrices range from 10% to 90%+ full once they are
filled in, so the dense representation is better.
This reduces the runtime of Check Nll builds of `inflate` by 32%, and
several other benchmarks by 1--5%.
It also increases max-rss of `clap-rs` by 30% and a couple of others by
up to 5%, while decreasing max-rss of `coercions` by 14%. I think the
speed-ups justify the max-rss increases.
r? @nikomatsakis
Using a `BTreeMap` to represent rows in the bit matrix is really slow.
This patch changes things so that each row is represented by a
`BitVector`. This is a less sparse representation, but a much faster
one.
As a result, `SparseBitSet` and `SparseChunk` can be removed.
Other minor changes in this patch.
- It renames `BitVector::insert()` as `merge()`, which matches the
terminology in the other classes in bitvec.rs.
- It removes `SparseBitMatrix::is_subset()`, which is unused.
- It reinstates `RegionValueElements::num_elements()`, which #52190 had
removed.
- It removes a low-value `debug!` call in `SparseBitMatrix::add()`.
We used to hardcode that we wanted the liveness of *all* variables.
This can now be configured by selecting an alternative index type
V and providing a (partial) map from locals to that new type V.
nll experiment: compute SCCs instead of iterative region solving
This is an attempt to speed up region solving by replacing the current iterative dataflow with a SCC computation. The idea is to detect cycles (SCCs) amongst region constraints and then compute just one value per cycle. The graph with all cycles removed is of course a DAG, so we can then solve constraints "bottom up" once the liveness values are known.
I kinda ran out of time this morning so the last commit is a bit sloppy but I wanted to get this posted, let travis run on it, and maybe do a perf run, before I clean it up.
The strategy is this:
- we compute SCCs once all outlives constraints are known
- we allocate a set of values **per region** for storing liveness
- we allocate a set of values **per SCC** for storing the final values
- when we add a liveness constraint to the region R, we also add it
to the final value of the SCC to which R belongs
- then we can apply the constraints by just walking the DAG for the
SCCs and union'ing the children (which have their liveness
constraints within)
There are a few intermediate refactorings that I really ought to have
broken out into their own commits:
- reverse the constraint graph so that `R1: R2` means `R1 -> R2` and
not `R2 -> R1`. This fits better with the SCC computation and new
style of inference (`->` now means "take value from" and not "push
value into")
- this does affect some of the UI tests, since they traverse the
graph, but mostly the artificial ones and they don't necessarily
seem worse
- put some things (constraint set, etc) into `Rc`. This lets us root
them to permit mutation and iteration. It also guarantees they don't
change, which is critical to the correctness of the algorithm.
- Generalize various helpers that previously operated only on points
to work on any sort of region element.
introduce dirty list to liveness, eliminate `ins` vector
At least in my measurements, this seems to knock much of the liveness computation off the profile.
r? @Zoxc
cc @nnethercote
