[OwnershipUtils] Classify moves from limited-use values as redundant. #64448
Conversation
Moves from limited use values are redundant. When a move separates a non-escaping lifetime from an escaping lifetime, it is still redundant if the original lifetime couldn't be optimized because it's already as small as possible.
nate-chandler
force-pushed
the
eliminate-more-moves
branch
from
129b261 to
6f5114e
Compare
nate-chandler
changed the title
|
@swift-ci please test |
|
Is this overly conservative? The original value's lifetime won't be affected if the |
That's true--the moved-to value's lifetime, however, would be affected if the moved-from value escaped. We don't want to introduce escapes into the moved-to value's lifetime if it doesn't already escape. This patch does a cheap check (original is not a phi and its only user is the move) that the original doesn't escape and returns early that the move_value is redundant if it doesn't. Afterwards, it compares the escaping of the original and the moved-to value. If the original doesn't escape, it checks only whether the move is the only consuming use (now that the original value is known not to escape unlike before). Am I missing something? |
| auto originalHasEscape = hasPointerEscape(original); | ||
|
|
||
| // (3) Escaping matches? (Expensive check, saved for last.) | ||
| if (moveHasEscape != originalHasEscape) { |
There was a problem hiding this comment.
Might be more clear:
if (moveHasEscape == originalHasEscape)
return true
| if (hasPointerEscape(mvi) != hasPointerEscape(original)) { | ||
| // The move doesn't alter constraints: ownership and lexicality match. | ||
|
|
||
| auto *singleUser = |
|
Will post a follow-up to address those two. |
When a move separates a non-escaping lifetime from an escaping lifetime, it is still redundant if the original lifetime couldn't be optimized because it's already as small as possible.