[NLL] Remove LiveVar
#58505
[NLL] Remove LiveVar
#58505
Conversation
It was used in `compute_for_all_locals` to iterate only the `Local`s that need liveness analysis (filtered through `compute`). Instead, explicitly extract that reduced set (as `live_locals`) in `trace` and pass it to `compute_for_all_locals`. Change the variable type used in `compute_for_all_locals` from `LiveVar` to `Local` and do the same for its helper functions (and the functions in `LocalUseMap` they rely on): * `add_defs_for` -> `LocalUseMap::defs` * `compute_use_live_points_for` -> `LocalUseMap::uses` * `compute_drop_live_points_for` -> `LocalUseMap::drops` Push back the use of `LiveVar` to the `LocalUseMap` (where the other `NllLivenessMap` remains embedded) functions which internally do the `from_local` conversion.
Extend `LocalUseMap`'s `IndexVec`s that track def/use/drop data to store the original `Local` indexes and not the compacted `LiveVar` ones (favoring speed and code simplicity over space). Remove the `NllLivenessMap` embedded inside it since it's no longer needed to perform the `LiveVar`/`Local` conversion.
Extract the `compute` logic (now renamed `compute_live_locals`) from `NllLivenessMap` to the `liveness` module. Remove the unused structures.
With `NllLivenessMap` and `LiveVar` removed, the `IdentityMap` (remaining structure implementing the `LiveVariableMap` trait) loses its meaning. Specialize the `LiveVarSet` to a `BitSet<Local>` removing the `V` and related parameters. The `LiveVarSet<V>` was only being used as `LiveVarSet<Local>` so this commit doesn't bring any change to the logic, it just removes an unused parameter (that without `LiveVar` now, it couldn't have been specialized to anything but `Local`).
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
rust-highfive
added
the
S-waiting-on-review
|
@bors try |
[NLL] Remove `LiveVar` The `LiveVar` type (and related) made it harder to reason about the code. It seemed as an abstraction that didn't bring any useful concept to the reader (when transitioning from the RFC theory to the actual implementation code). It achieved a compactness in the vectors storing the def/use/drop information that was related only to the `LocalUseMap`. This PR went in the other direction and favored time over memory (but this decision can be easily reverted to the other side without reintroducing `LiveVar`). What this PR aims at is to clarify that there's no significant transformation between the MIR `Local` and the `LiveVar` (now refactored as `live_locals: Vec<Local>`): we're just filtering (not mapping) the entire group of `Local`s into a meaningful subset that we should perform the liveness analysis on. As a side note, there is no guarantee that the liveness analysis is performed only on (what the code calls) "live" variables, if the NLL facts are requested it will be performed on *any* variable so there can't be any assumptions on that regard. (Still, this PR didn't change the general naming convention to reduce the number of changes here and streamline the review process). **Acceptance criteria:** This PR attempts to do only a minor refactoring and not to change the logic so it can't have any performance impact, particularly, it can't lose any of the significant performance improvement achieved in the great work done in #52115. r? @nikomatsakis
|
☀️ Test successful - checks-travis |
|
@schomatis IIRC, we no longer even use the Regardless, I am going to re-assign this to @matthewjasper for review -- @matthewjasper, I hope that's ok. If not, please ping me on Zulip and I'll find someone else. I'm basically trying to work through a backlog of reviews so I fear I won't be able to get to it in a timely fashion. |
@nikomatsakis No, my (inexperienced) understanding is that we do use the (There is a case, when we request to "dump facts from NLL analysis", which I'm not sure how frequent that is, when in fact we do compute liveness for all variables. This also made the |
|
Ping from triage, @matthewjasper, we eagerly await your review :) |
|
Looks good, but I want to check how much memory this ends up using. @rust-lang/infra can I have a perf run? |
@matthewjasper ping :) |
|
@rust-timer build 0baf2b5 |
|
Success: Queued 0baf2b5 with parent eac0908, comparison URL. |
|
Finished benchmarking try commit 0baf2b5 |
|
Perf looks good @bors r+ |
|
📌 Commit ae5f722 has been approved by |
bors
added
S-waiting-on-bors
…sper [NLL] Remove `LiveVar` The `LiveVar` type (and related) made it harder to reason about the code. It seemed as an abstraction that didn't bring any useful concept to the reader (when transitioning from the RFC theory to the actual implementation code). It achieved a compactness in the vectors storing the def/use/drop information that was related only to the `LocalUseMap`. This PR went in the other direction and favored time over memory (but this decision can be easily reverted to the other side without reintroducing `LiveVar`). What this PR aims at is to clarify that there's no significant transformation between the MIR `Local` and the `LiveVar` (now refactored as `live_locals: Vec<Local>`): we're just filtering (not mapping) the entire group of `Local`s into a meaningful subset that we should perform the liveness analysis on. As a side note, there is no guarantee that the liveness analysis is performed only on (what the code calls) "live" variables, if the NLL facts are requested it will be performed on *any* variable so there can't be any assumptions on that regard. (Still, this PR didn't change the general naming convention to reduce the number of changes here and streamline the review process). **Acceptance criteria:** This PR attempts to do only a minor refactoring and not to change the logic so it can't have any performance impact, particularly, it can't lose any of the significant performance improvement achieved in the great work done in #52115. r? @nikomatsakis
|
☀️ Test successful - checks-travis, status-appveyor |
The
LiveVartype (and related) made it harder to reason about the code. It seemed as an abstraction that didn't bring any useful concept to the reader (when transitioning from the RFC theory to the actual implementation code).It achieved a compactness in the vectors storing the def/use/drop information that was related only to the
LocalUseMap. This PR went in the other direction and favored time over memory (but this decision can be easily reverted to the other side without reintroducingLiveVar).What this PR aims at is to clarify that there's no significant transformation between the MIR
Localand theLiveVar(now refactored aslive_locals: Vec<Local>): we're just filtering (not mapping) the entire group ofLocals into a meaningful subset that we should perform the liveness analysis on.As a side note, there is no guarantee that the liveness analysis is performed only on (what the code calls) "live" variables, if the NLL facts are requested it will be performed on any variable so there can't be any assumptions on that regard. (Still, this PR didn't change the general naming convention to reduce the number of changes here and streamline the review process).
Acceptance criteria: This PR attempts to do only a minor refactoring and not to change the logic so it can't have any performance impact, particularly, it can't lose any of the significant performance improvement achieved in the great work done in #52115.
r? @nikomatsakis