[NFC] Utilities for lifetime dependent coroutines #77675
Merged
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
A begin_apply token may be used by operands that do not end the coroutine: mark_dependence. We need an API that gives us only the coroutine-ending uses. This blocks ~Escapable accessors. end_borrow is considered coroutine-ending even though it does not actually terminate the coroutine. We cannot simply ask isLifetimeEnding, because end_apply and abort_apply do not end any lifetime.
Only return the EndApplyInst and AbortApplyInst uses.
To be consistent with the C++ implementation.
Add endInstructions requirement so it can be called on an unknown ScopedInstruction.
AccessBase already identifies a base address as either a .global (addressor) or a .pointer. When initializing an AccessBase from a pointer_to_address, precisely identify one of these kinds of accesses, rather than simply marking it .unidentified. This used to be a special case in the AccessPathWalker. But that's not the right place to handle it.
LifetimeDependence uses the address of the AccessBase to compute liveness. It is more convenient to switch over all AccessBase kinds here rather than force all clients to do it.
And simplify enclosingAccessScope. These two APIs now directly compute what is being asked for. Previously, each invocation of enclosingAccessScope would recompute the base and all nested scopes, but throw away that information. Sometimes we do not want to compute that information, and other times we need all of it. Instead, provide separate APIs that do exactly what is needed. These are common APIs used by other utilities. This avoids quadratic traversals in those cases. It is also easier to understand and debug. These utilities will be used in LifetimeDependenceScopeFixup.
Some utilities, like Builder.insert(after:) pass a Builder object that represents an insertion point. That insertion point is sometimes needed to determine which instructions to create (endApply vs. abortApply). But there is no way to recover the insertion point. We don't want to simply return an instruction, because that could be interpreted in different ways. Instead we provide insertion block, but only in those situations where it makes sense and can't be used incorrectly.
|
@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.
A set of NFC utilities for working with coroutines. These are currently blocking the enablement of lifetime dependent
_readaccessors.