[move-only-addresses] Slicing some patches off of the larger patch. #60511
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…init]/load [copy] on move only values in Raw SIL. This is already an invariant for copy_value and now that I am implementing move semantics for addresses, it makes sense to ban those in a similar way. Specifically, we are enforcing the invariant that move only types are allowed to be copied in Raw SIL, but not in later parts of SIL. For those who are unaware, we then run checkers later to validate that we preserve ownership semantics.
…w SIL, but not in later SIL stages. Since I am going to start enforcing this invariant more broadly, I want to document it in SIL.rst. I also included a discussion explaining why we maintain this invariant: it enables SILGen to use a simple algorithm to insert copies/us to clean that up using a diagnostic guaranteed optimization pass which runs on Raw SIL.
…ve copy_value a move only value as an operand. I am enforcing this in the verifier, so it makes sense to document in SIL.rst.
There really isn't a point in repeating the verbage from copy_value. So I removed that and just referred back to the copy_value documentation and focused instead on what makes explicit_copy_value different semantically from copy_value, how it is used to work around the invariant in Canonical SIL that move only typed values can not be copied. This is useful for: 1. Implementing an explicit copy for no implicit copy types. 2. When the move checker errors since it can't produce a move only solution for a value, we change all of the copies into explicit_copy_value. We need some sort of copy to ensure later once we are in Canonical SIL, Ownership SSA is correct /and/ we maintain the no copy of move only typed values in Canonical SIL.
This is exactly like copy_addr except that it is not viewed from the verifiers perspective as an "invalid" copy of a move only value. It is intended to be used in two contexts: 1. When the move checker emits a diagnostic since it could not eliminate a copy, we still need to produce valid SIL without copy_addr on move only types since we will hit canonical SIL eventually even if we don't actually codegen the SIL. The pass can just convert said copy_addr to explicit_copy_addr and everyone is happy. 2. To implement the explicit copy function for address only types.
gottesmm
force-pushed
the
pr-0796eed23b86f5812f817b15b928dbe11485c361
branch
from
32d72c7 to
5baf2af
Compare
|
@swift-ci test |
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.
In this PR, I am just slicing off some work from the larger series of address move only patches that I am preparing. Specifically this: