diff options
| author | bors <bors@rust-lang.org> | 2023-07-17 04:45:10 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2023-07-17 04:45:10 +0000 |
| commit | 6f65ef57177ce0095171f70d0b010567c35e68cc (patch) | |
| tree | 4cbec4e75fc096768d16d3685122de1df756bb83 /src | |
| parent | 299179e69457125e77be1489531bca0b9ee1af48 (diff) | |
| parent | 4e117a9b4ef8d07532b141b7cba02f815e1fc376 (diff) | |
| download | rust-6f65ef57177ce0095171f70d0b010567c35e68cc.tar.gz rust-6f65ef57177ce0095171f70d0b010567c35e68cc.zip | |
Auto merge of #113562 - saethlin:larger-incr-comp-offset, r=nnethercote
Use u64 for incr comp allocation offsets
Fixes https://github.com/rust-lang/rust/issues/76037
Fixes https://github.com/rust-lang/rust/issues/95780
Fixes https://github.com/rust-lang/rust/issues/111613
These issues are all reporting ICEs caused by using `u32` to store offsets to allocations in the incremental compilation cache. This PR aims to lift that limitation by changing the offset type in question to `u64`.
There are two perf runs in this PR. The first reports a regression, and the second does not. The changes are the same in both. I rebased the PR then did the second perf run because I noticed that the primary regression in it was very commonly seen in spurious regression reports.
I do not know what the perf run will report when this is merged. I would not be surprised to see regression or neutral, but the cachegrind diffs for the regression point at `try_mark_previous_green` which is a common source of inexplicable regressions and I don't think should be perturbed by this PR.
I'm not opposed to adding a regression test such as
```rust
fn main() {
println!("{}", [37; 1 << 30].len());
}
```
But that program takes 1 minute to compile and consumes 4.6 GB of memory then writes that much to disk. Is that a concerning amount of resource use for a test?
r? `@nnethercote`
Diffstat (limited to 'src')
0 files changed, 0 insertions, 0 deletions
