about summary refs log tree commit diff
path: root/src
diff options
context:
space:
mode:
authorbors <bors@rust-lang.org>2023-07-17 04:45:10 +0000
committerbors <bors@rust-lang.org>2023-07-17 04:45:10 +0000
commit6f65ef57177ce0095171f70d0b010567c35e68cc (patch)
tree4cbec4e75fc096768d16d3685122de1df756bb83 /src
parent299179e69457125e77be1489531bca0b9ee1af48 (diff)
parent4e117a9b4ef8d07532b141b7cba02f815e1fc376 (diff)
downloadrust-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