-
Notifications
You must be signed in to change notification settings - Fork 13k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[perf] Loan liveness frontier slowness evaluation #112432
Conversation
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
⌛ Trying commit fff2a32f5c6e40599f9fcc713323037667f9d7e8 with merge 272c25090e41e0e5d04bfe45e3c04016d4c6b0a6... |
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (272c25090e41e0e5d04bfe45e3c04016d4c6b0a6): comparison URL. Overall result: ❌ regressions - ACTION NEEDEDBenchmarking 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 @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis 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.
CyclesResultsThis 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.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 648.127s -> 661.135s (2.01%) |
That's more like it. |
fff2a32
to
db6a863
Compare
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
⌛ Trying commit db6a863c8f0a04969e7e628ce2a6ffffde30769f with merge 48ab5baa844649d42689b368717f6140000cd402... |
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (48ab5baa844649d42689b368717f6140000cd402): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDBenchmarking 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 @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesResultsThis 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.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 649.935s -> 649.406s (-0.08%) |
db6a863
to
6c85c49
Compare
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
Compute NLL loan scopes using the polonius model Draft PR to guide discussion for this monday's types team meeting, where the plan is to read this and review as a group. 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. There are a few fixmes left, and I'll still work on them before the meeting. A couple of notes: - I started prototyping this a while ago so it follows the structure of the _previous_ NLL `OutOfScopePrecomputer`, before the couple recent refactors. They probably could/should look the same instead. - there are some assumptions about placeholders, free regions, and member constraints that I think hold, and they're documented in the code - this passes all the UI tests with `-Zpolonius=next` -- though the additional work done can be felt on the huge numeric/float tests, but the perf is [not terrible](rust-lang#112432 (comment)) and there are a bunch of ways to improve it in the future. (cc `@matthewjasper` since you asked to be pinged about it) r? `@ghost`
this allows to opt into using the legacy version or the in-tree prototype
da792f0
to
99e0fc2
Compare
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
[perf] Loan liveness frontier slowness evaluation It doesn't feel that much slower on UI tests, but will probably scale badly on realistic code, so let's see how terribly it performs. r? `@ghost`
99e0fc2
to
8d5cbc6
Compare
the previous run is going to be busted but the force push didn't kill it. tests are now fixed @bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
[perf] Loan liveness frontier slowness evaluation It doesn't feel that much slower on UI tests, but will probably scale badly on realistic code, so let's see how terribly it performs. r? `@ghost`
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (a2f1897): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDBenchmarking 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 @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis 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.
CyclesResultsThis 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.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 623.65s -> 622.591s (-0.17%) |
Compute NLL loan scopes using the polonius model 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](rust-lang#112432 (comment)) 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.
Compute NLL loan scopes using the polonius model 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](rust-lang/rust#112432 (comment)) 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.
It doesn't feel that much slower on UI tests, but will probably scale badly on realistic code, so let's see how terribly it performs.
r? @ghost