Clean up logic around live locals in generator analysis#71956
Merged
bors merged 9 commits intoMay 22, 2020
Conversation
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Resolves #69902. Requires #71893.
I've found it difficult to make changes in the logic around live locals in
generator/transform.rs. It uses a custom dataflow analysis,MaybeRequiresStorage, that AFAICT computes whether a local is either initialized or borrowed. That analysis is usingbeforeeffects, which we should try to avoid if possible because they are harder to reason about than ones only using the unprefixed effects. @pnkfelix has suggested removing "before" effects entirely to simplify the dataflow framework, which I might pursue someday.This PR replaces
MaybeRequiresStoragewith a combination of the existingMaybeBorrowedLocalsand a newMaybeInitializedLocals.MaybeInitializedLocalsis justMaybeInitializedPlaceswith a coarser resolution: it works on whole locals instead of move paths. As a result, I was able to simplify the logic incompute_storage_conflictsandlocals_live_across_suspend_points.This is not exactly equivalent to the old logic; some generators are now smaller than before. I believe this was because the old logic was too conservative, but I'm not as familiar with the constraints as the original implementers were, so I could be wrong. For example, I don't see a reason the size of the
mixed_sizesfuture couldn't be 5K. It went from 7K to 6K in this PR.r? @jonas-schievink @tmandry