Compute NLL loan scopes using the polonius model

[lqd]

For a location-insensitive analysis (that is, without expressiveness improvements for users yet), this PR implements loans going out of scope using reachability and liveness, rather than checking if the issuing region's values contain a given CFG point. This is equivalent to NLL scopes and computes the same data.

r? @matthewjasper

A couple of notes:

• there are some assumptions about SCC representatives, placeholders, free regions, and member constraints that I believe hold, and they're documented in the code
• this passes all the UI tests with -Zpolonius=next -- the perf is not terrible and there are a bunch of ways to improve it in the future.
• there's a fixme left, hopefully Matthew you know a clean way to get the information it mentions.

[lqd]

@matthewjasper there are still things in there that I'd like to clean up, (e.g. I'm currently seeing whether some of the reachability computation can be done in liveness, and may try to make the look a bit more like the refactored CFG traversal) but I don't think they're absolutely necessary and won't change the core of the PR: you could already take a look whether you approve of the direction. It'd be greatly appreciated 🙏

[matthewjasper]

Overall this approach seems fine as a first step.

It would be nice to have this "rebased" on the changes in #111759 to make determining the differences easier.

[lqd]

Thanks for taking a look.

It would be nice to have this "rebased" on the changes in #111759 to make determining the differences easier.

Sure, I'll try to tackle that soon.

It'll still have to be somewhat different, compared to diffing over https://github.com/lqd/rust/blob/eaddc3707520988f8bc2d267cb192d2f0c63ee80/compiler/rustc_borrowck/src/dataflow.rs#L155-L231 prior to the refactor and where it's easier to see that basically only the if !self.regioncx.region_contains(borrow_region, location) has changed -- as #111759 and its followup make more use of regions as sets of points during the CFG walk.

[lqd]

let's see the hit liveness takes to do additional checks on whether polonius is enabled

@bors try @rust-timer queue

[bors]

⌛ Trying commit 51ed991 with merge 263b07f...

[bors]

☀️ Try build successful - checks-actions
Build commit: 263b07f (263b07f838cae7fed15b3cb6147c2e0b0b1b44ec)

[rust-timer]

Finished benchmarking commit (263b07f): comparison URL.

Overall result: ❌ regressions - ACTION NEEDED

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

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

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.8%	[0.7%, 0.9%]	4
Regressions ❌ (secondary)	0.7%	[0.7%, 0.8%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.8%	[0.7%, 0.9%]	4

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 621.055s -> 621.438s (0.06%)
Artifact size: 271.92 MiB -> 271.98 MiB (0.02%)

[lqd]

This also should partly be noise: cachegrind only shows a 0.1% diff on helloworld. And the noise bumps shown below from the last few days, are to similar icounts within 0.03% of this run.

Similar noise on these benchmarks, with the same magnitude, is also currently present in other PRs, e.g. here.

That seems acceptable at least to start an initial review.

@rustbot ready

[jackh726]

I don't think there's anything here that would cause me not to feel comfortable r+ing, but some thoughts nonetheless :)

[jackh726]

Could certainly do a binary search here - but I'm not sure the complexity would be helpful. What could be interesting is going from end to start (depends how often we expect loans to be live at the end of a block versus dying within (and where)

[jackh726]

@bors r+

I think we can get this into tree. It's still behind a flag, so not worried.

[bors]

📌 Commit 3dcff00 has been approved by jackh726

It is now in the queue for this repository.

[matthiaskrgr]

@bors p=6 moving over my rollup

[bors]

⌛ Testing commit 3dcff00 with merge c1691db...

[bors]

☀️ Test successful - checks-actions
Approved by: jackh726
Pushing c1691db to master...

[rust-timer]

Finished benchmarking commit (c1691db): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.2%	[-0.2%, -0.2%]	2
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.7%	[-2.8%, -2.7%]	2
All ❌✅ (primary)	-	-	0

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 628.128s -> 628.448s (0.05%)
Artifact size: 271.28 MiB -> 271.30 MiB (0.01%)