Remove fewer Storage calls in CopyProp and GVN

[ohadravid]

Modify the CopyProp and GVN MIR optimization passes to remove fewer Storage{Live,Dead} calls, allowing for better optimizations by LLVM - see #141649.

Details

The idea is to use a new MaybeUninitializedLocals analysis and remove only the storage calls of locals that are maybe-uninit when accessed in a new location.

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[matthiaskrgr]

@bors try @rust-timer queue

[bors]

⌛ Trying commit d24d035 with merge ef7d206...

[bors]

☀️ Try build successful - checks-actions
Build commit: ef7d206 (ef7d20666974f0dac45b03e051f2e283f9d9f090)

[rust-timer]

Finished benchmarking commit (ef7d206): comparison URL.

Overall result: ❌ regressions - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	0.3%	[0.2%, 0.4%]	8
Regressions ❌ (secondary)	0.3%	[0.2%, 0.4%]	7
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.3%	[0.2%, 0.4%]	8

Max RSS (memory usage)

Results (primary 0.7%, secondary 3.4%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	3.5%	[1.8%, 5.0%]	5
Regressions ❌ (secondary)	3.4%	[3.4%, 3.4%]	1
Improvements ✅ (primary)	-3.9%	[-6.5%, -2.0%]	3
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.7%	[-6.5%, 5.0%]	8

Cycles

Results (primary -0.6%, secondary -0.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	3.8%	[3.8%, 3.8%]	1
Improvements ✅ (primary)	-0.6%	[-0.6%, -0.6%]	1
Improvements ✅ (secondary)	-4.1%	[-4.1%, -4.1%]	1
All ❌✅ (primary)	-0.6%	[-0.6%, -0.6%]	1

Binary size

Results (primary 0.0%, secondary 0.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	0.2%	[0.0%, 0.8%]	10
Regressions ❌ (secondary)	0.1%	[0.0%, 0.1%]	5
Improvements ✅ (primary)	-0.2%	[-0.8%, -0.0%]	8
Improvements ✅ (secondary)	-0.2%	[-0.2%, -0.2%]	1
All ❌✅ (primary)	0.0%	[-0.8%, 0.8%]	18

Bootstrap: 757.399s -> 756.065s (-0.18%)
Artifact size: 372.20 MiB -> 372.12 MiB (-0.02%)

[ohadravid]

@matthiaskrgr - I updated the impl to stop re-checking once a head is found to be maybe-dead, which should be a bit better

[matthiaskrgr]

@bors try @rust-timer queue

[bors]

⌛ Trying commit 905e968 with merge c0a2949...

[cjgillot]

Should this check happen in Replacer::visit_local, and move the replacement of storage statements to a dedicated cleanup visitor?

[bors]

☀️ Try build successful - checks-actions
Build commit: c0a2949 (c0a294957df10fc3880e1677c72c0cf122485509)

[ohadravid]

Should this check happen in Replacer::visit_local

I'm not sure how to make this work: using ResultsCursor requires a &body, but it's not possible to have that while running a MutVisitor since it requires a &mut body.

Is there a different way to do this?

[rust-timer]

Finished benchmarking commit (c0a2949): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	0.3%	[0.2%, 0.4%]	9
Regressions ❌ (secondary)	0.3%	[0.2%, 0.4%]	7
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.2%	[-0.2%, -0.2%]	1
All ❌✅ (primary)	0.3%	[0.2%, 0.4%]	9

Max RSS (memory usage)

Results (primary -0.1%, secondary -1.3%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	4.2%	[3.4%, 5.8%]	4
Regressions ❌ (secondary)	3.1%	[3.1%, 3.1%]	1
Improvements ✅ (primary)	-4.4%	[-6.6%, -1.8%]	4
Improvements ✅ (secondary)	-5.8%	[-5.8%, -5.8%]	1
All ❌✅ (primary)	-0.1%	[-6.6%, 5.8%]	8

Cycles

Results (secondary -1.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.3%	[2.3%, 2.3%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.6%	[-2.6%, -2.5%]	2
All ❌✅ (primary)	-	-	0

Binary size

Results (primary -0.0%, secondary 0.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	0.2%	[0.0%, 0.8%]	10
Regressions ❌ (secondary)	0.1%	[0.0%, 0.1%]	5
Improvements ✅ (primary)	-0.2%	[-0.8%, -0.0%]	8
Improvements ✅ (secondary)	-0.2%	[-0.2%, -0.2%]	1
All ❌✅ (primary)	-0.0%	[-0.8%, 0.8%]	18

Bootstrap: 756.494s -> 757.685s (0.16%)
Artifact size: 372.15 MiB -> 372.11 MiB (-0.01%)

[tmiasko]

SsaLocals::borrowed_locals()[local] describes whether local is borrowed, not whether any local in its copy class is borrowed. An example that doesn't work as it supposed to:

#![feature(custom_mir, core_intrinsics, freeze)]
extern crate core;
use core::intrinsics::mir::*;
use core::marker::Freeze;

#[custom_mir(dialect = "runtime")]
pub fn f<T: Copy + Freeze>(_1: (T, T)) -> T {
    mir! {
        let _2: T;
        let _3: T;
        let _4: &T;
        {
            StorageLive(_2);
            _2 = _1.0;
            _3 = _2;
            _4 = &_3;
            StorageDead(_2);
            RET = *_4;
            Return()
        }
    }
}

$ rustc +stage1 b.rs --crate-type=lib -Zmir-opt-level=0 -Zmir-enable-passes=+CopyProp -Zunpretty=mir -Copt-level=1
fn f(_1: (T, T)) -> T {
    let mut _0: T;
    let mut _2: T;
    let mut _3: T;
    let mut _4: &T;

    bb0: {
        StorageLive(_2);
        _2 = copy (_1.0: T);
        _4 = &_2;
        StorageDead(_2);
        _0 = copy (*_4);
        return;
    }
}

I think it should be fine to allow the head itself to be borrowed (it is only all other locals from the copy class that cannot be borrowed).

[ohadravid]

Oh I see, I read the compute_copy_classes comment but assumed it referred to ssa.borrowed_locals(), not the one it computes internally.

[ohadravid]

Add this test and pushed the correct fix.
I do get reordered output for some tests (like tests/mir-opt/pre-codegen/derived_ord.rs) and I'm not sure why, but the fixed impl now produces the correct output for this test.

[cjgillot]

@ohadravid do you mind merging this PR and #142819? Both should use the same code to decide whether to keep or remove storage statements. And I fear that having 2 PRs mean that @tmiasko and I won't see each other ideas and give you diverging advice.

[ohadravid]

@cjgillot , @tmiasko - merged both PR here.

Current impls are based on the new MaybeUninitializedLocals analysis in both passes, with all the new tests cases passing.

Does GVN require an additional check against borrowed locals like mentioned in #142531 (comment)?

Both only do the more complex analysis when tcx.sess.emit_lifetime_markers(), so they shouldn't negatively affect check/debug builds, but the last perf run did show some changes to them as well.

And thank you both for reviewing these and explaining everything! 🙏