[BarrierAccessScopes] Handle end_access instructions' barrierness introduced during run. #77908
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
As the utility runs, new gens may become local: as access scopes are determined to contain deinit barriers, their `end_access` instructions become kills; if such an `end_access` occurs in the same block above an initially-non-local gen, that gen is now local. Previously, it was asserted that initially-non-local gens would not encounter when visiting the block backwards from that gen. Iteration would also _stop_ at the discovered kill, if any. As described above, the assertion was incorrect. Stopping at the discovered kill was also incorrect. It's necessary to continue walking the block after finding such a new kill because the book-keeping the utility does for which access scopes contain barriers. Concretely, there are two cases: (1) It may contain another `end_access` and above it a deinit barrier which must result in that second scope becoming a deinit barrier. (2) Some of its predecessors may be in the region, all the access scopes which are open at the begin of this block must be unioned into the set of scopes open at each predecessors' end, and more such access scopes may be discovered above the just-visited `end_access`. Here, both the assertion failure and the early bailout are fixed by walking from the indicated initially-non-local gen backwards over the entire block, regardless of whether a kill was encountered. If a kill is encountered, it is asserted that the kill is an `end_access` to account for the case described above. rdar://139840307
|
@swift-ci please test |
|
@swift-ci please test source compatibility |
|
@swift-ci please apple silicon benchmark |
|
@swift-ci please test macos platform |
|
@swift-ci please test linux platform |
This was referenced Dec 5, 2024
6.1: [BarrierAccessScopes] Handle end_access instructions' barrierness introduced during run.
#77969
Merged
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.
As the utility runs, new gens may become local: as access scopes are determined to contain deinit barriers, their
end_accessinstructions become kills; if such anend_accessoccurs in the same block above an initially-non-local gen, that gen is now local.Previously, it was asserted that kills would not be encountered when visiting a block backwards from an initially-non-local gen. As described above, the assertion was incorrect.
Iteration would also stop at the discovered kill, if any. That too was incorrect. To continue walking the block after finding such a newly discovered kill is needed by the book-keeping the utility does for which access scopes contain barriers: there may be more
end_accessinstructions. Concretely, there are two cases: (1) The block may contain anotherend_accessand above it a deinit barrier which must result in that second scope becoming a deinit barrier. (2) Some of the block's predecessors may be in the region, all the access scope which are open at the begin of this block must be unioned into the set of scopes open at each predecessors' end, and more such access scopes may be discovered above the just-visitedend_access.Here, both the assertion failure and the early bailout are fixed by walking from the indicated initially-non-local gen backwards over the entire block, regardless of whether a kill was encountered. If a kill is encountered, it is asserted that the kill is an
end_accessto account for the case described above.rdar://139840307