Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

use sparse bitsets instead of dense ones for NLL results #48170

Closed
nikomatsakis opened this issue Feb 12, 2018 · 2 comments
Closed

use sparse bitsets instead of dense ones for NLL results #48170

nikomatsakis opened this issue Feb 12, 2018 · 2 comments
Assignees
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup. I-compilemem Issue: Problems and improvements with respect to memory usage during compilation. I-compiletime Issue: Problems and improvements with respect to compile times. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@nikomatsakis
Copy link
Contributor

As part of #47879, it seems clear that using dense bitsets is going to be a problem for NLL sooner or later. We should move to a sparse set. I think that the BTreeMap idea sketched in #47575 may be a good choice.

The NLL region representation is defined here:

/// Stores the values for a set of regions. These are stored in a
/// compact `BitMatrix` representation, with one row per region
/// variable. The columns consist of either universal regions or
/// points in the CFG.
#[derive(Clone)]
pub(super) struct RegionValues {
elements: Rc<RegionValueElements>,
matrix: BitMatrix,
/// If cause tracking is enabled, maps from a pair (r, e)
/// consisting of a region `r` that contains some element `e` to
/// the reason that the element is contained. There should be an
/// entry for every bit set to 1 in `BitMatrix`.
causes: Option<CauseMap>,
}

In particular, the field matrix uses aBitMatrix. The "rows" in the matrix are inference variables, and the columns are the indices defined here (either cfg points or universal regions).

I think we should add a new type SparseBitMatrix that offers the same API as BitMatrix. It might be represented with a Vec<SparseSet>, per #47575, where SparseSet is a bit set represented as sketched in this comment. Or it might even just use a single SparseSet internally, where each bit is indexed by an index I = (row * num_columns) + column.

@nikomatsakis nikomatsakis added I-compiletime Issue: Problems and improvements with respect to compile times. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. I-compilemem Issue: Problems and improvements with respect to memory usage during compilation. WG-compiler-nll labels Feb 12, 2018
@nikomatsakis nikomatsakis added this to the NLL: Performance is good milestone Feb 12, 2018
@nikomatsakis
Copy link
Contributor Author

@spastorino indicated that they wanted to give this a try. @eddyb -- is your sparsebitmatrix stuff working out? Is current version on a branch somewhere?

@eddyb
Copy link
Member

eddyb commented Feb 12, 2018

@nikomatsakis I've been using the SparseBitSet from #47575 (comment), w/o a matrix on top of it.

@TimNN TimNN added the C-cleanup Category: PRs that clean code up or issues documenting cleanup. label Feb 13, 2018
Manishearth added a commit to Manishearth/rust that referenced this issue Feb 23, 2018
…tsakis

Use sparse bitsets instead of dense ones for NLL results

This is for rust-lang#48170.

r? @nikomatsakis
@bors bors closed this as completed in ff9eb56 Feb 24, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup. I-compilemem Issue: Problems and improvements with respect to memory usage during compilation. I-compiletime Issue: Problems and improvements with respect to compile times. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants