| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This reverts commit 6810f5286b6b91daab06fc3dccb27d8c46f14349, reversing
changes made to 8586ec6980462c99a8926646201b2444d8938d29.
|
|
Remove bitslice.rs
As the comment in `bitslice.rs` says:
> FIXME: merge with `bitvec`
|
|
This requires the following changes.
- It moves parts of bitslice.rs into bitvec.rs: `bitwise()`,
`BitwiseOperator`, `bits_to_string()`.
- It changes `IdxSet` to just be a wrapper around `BitArray`.
- It changes `BitArray` and `BitVec` to use `usize` words instead of
`u128` words. (`BitSlice` and `IdxSet` already use `usize`.) Local
profiling showed `usize` was better.
- It moves some operations from `IdxSet` into `BitArray`:
`new_filled()`, `clear()`, `set_up_to()`, `trim_to()` (renamed
`clear_above()`), `words()` and `words_mut()`, `encode()` and
`decode(). The `IdxSet` operations now just call the `BitArray`
operations.
- It replaces `BitArray`'s iterator implementation with `IdxSet`'s,
because the latter is more concise. It also removes the buggy
`size_hint` function from `BitArray`'s iterator, which counted the
number of *words* rather than the number of *bits*. `IdxSet`'s
iterator is now just a thin wrapper around `BitArray`'s iterator.
- It moves some unit tests from `indexed_set.rs` to `bitvec.rs`.
|
|
Co-authored-by: nikomatsakis
|
|
It's basically just a less capable version of `SmallVec`.
|
|
NLL: experiment with inverting liveness
I got inspired to see what would happen here.
Fixes #52460
r? @pnkfelix
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Avoid many allocations for CStrings during codegen.
Giving in to my irrational fear of dynamic allocations. Let's see what perf says to this.
|
|
[nll] enable feature(nll) on various crates for bootstrap: part 4
#53172
r? @nikomatsakis
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use `ptr::eq` for comparing pointers
|
|
Also modify `SparseBitMatrix` so that it does not require knowing the
dimensions in advance, but instead grows on demand.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Stabilize num::NonZeroU*
Tracking issue: https://github.com/rust-lang/rust/issues/49137
|
|
Tracking issue: https://github.com/rust-lang/rust/issues/49137
|
|
It was introduced in #50240 to avoid an allocation when creating a new
BTreeMap, which gave some speed-ups. But then #50352 made that the
default behaviour for BTreeMap, so LazyBTreeMap is no longer necessary.
|
|
|
|
Implement LazyBTreeMap and use it in a few places.
This is a thin wrapper around BTreeMap that avoids allocating upon creation.
I would prefer to change BTreeMap directly to make it lazy (like I did with HashSet in #36734) and I initially attempted that by making BTreeMap::root an Option<>. But then I also had to change Iter and Range to handle trees with no root, and those types have stability markers on them and I wasn't sure if that was acceptable. Also, BTreeMap has a lot of complex code and changing it all was challenging, and I didn't have high confidence about my general approach.
So I prototyped this wrapper instead and used it in the hottest locations to get some measurements about the effect. The measurements are pretty good!
- Doing a debug build of serde, it reduces the total number of heap allocations from 17,728,709 to 13,359,384, a 25% reduction. The number of bytes allocated drops from 7,474,672,966 to 5,482,308,388, a 27% reduction.
- It gives speedups of up to 3.6% on some rustc-perf benchmark jobs. crates.io, futures, and serde benefit most.
```
futures-check
avg: -1.9% min: -3.6% max: -0.5%
serde-check
avg: -2.1% min: -3.5% max: -0.7%
crates.io-check
avg: -1.7% min: -3.5% max: -0.3%
serde
avg: -2.0% min: -3.0% max: -0.9%
serde-opt
avg: -1.8% min: -2.9% max: -0.3%
futures
avg: -1.5% min: -2.8% max: -0.4%
tokio-webpush-simple-check
avg: -1.1% min: -2.2% max: -0.1%
futures-opt
avg: -1.2% min: -2.1% max: -0.4%
piston-image-check
avg: -0.8% min: -1.1% max: -0.3%
crates.io
avg: -0.6% min: -1.0% max: -0.3%
```
@Gankro, how do you think I should proceed here? Is leaving this as a wrapper reasonable? Or should I try to make BTreeMap itself lazy? If so, can I change the representation of Iter and Range?
Thanks!
|
|
|
|
This is a thin wrapper around BTreeMap that avoids allocating upon
creation. It speeds up some rustc-perf benchmarks by up to 3.6%.
|
|
This permits easier iteration without having to worry about warnings
being denied.
Fixes #49517
|
|
Holy cow that's a lot of `cfg(stage0)` removed and a lot of new stable language
features!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The ena version has an improved interface. I suspect
`librustc_data_structures` should start migrating out to crates.io in
general.
|
