MaybeRequiresStorage
for generators is not necessary
#69902
Labels
A-coroutines
Area: Coroutines
C-cleanup
Category: PRs that clean code up or issues documenting cleanup.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Continuing from discussion in #69716.
MaybeRequiresStorage
(introduced in #60187 asRequiresStorage
) is one of four dataflow analyses used to determine what locals are live across yield points or live at the same time as other locals during the MIR generator pass. I don't see any reason we're not using a liveness analysis exclusively for this, with an additional check againstMaybeBorrowedLocals ∩ MaybeStorageLive
in cases where borrows can live across suspension points (immovable generators).MaybeRequiresStorage
is basicallyMaybeStorageLive
with some additional logic that kills locals after they are moved out of. It also incorporates theMaybeBorrowedLocals
analysis as part of its transfer function, which is probably unnecessary, since we could check the results ofMaybeBorrowedLocals
directly at each yield point. If there is often a large gap between the point at which a local is moved out of and the point at which it is markedStorageDead
, we could augmentMaybeStorageLive
to kill locals when they are moved out of.The liveness analysis in
librustc_mir/util/liveness.rs
will implicitly handle moved-from locals as long as there are no future accesses to them, which is what causes a variable to be marked as live.I'd like refactor the liveness parts of the MIR generator pass, but will wait for buy-in from its authors. I think that basing the current storage optimization on a combination of a few well-known dataflow analyses will make it easier to reason about and therefore fine-tune. This will involve using the liveness analysis (plus
MaybeBorrowedLocals
/MaybeStorageLive
inside immovable generators) forcompute_storage_conflicts
. Does anyone see a problem with this? @tmandry @jonas-schievinkThe text was updated successfully, but these errors were encountered: