6.2: [DestroyAddrHoisting] Don't fold into read access. #82573
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
Narrowly fix a long-standing bug where destroy_addrs would be hoisted into read access scopes, leaving the scope as a read despite the fact that it modifies memory. This is a problem for utilities which expect access scopes to provide correct summaries. Do this by refusing to fold into access scopes which are marked `[read]`. In a follow-up, we can reenable this folding, promoting each access scope to a modify. Doing so requires checking that there are no access scopes which overlap with any of the access scopes which would be promoted to modify. rdar://154407327
|
@swift-ci please test |
tbkka
approved these changes
Jun 27, 2025
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.
Explanation: Bail out of an optimization in DestroyAddrHoisting when it's invalid.
The pass folds
destroy_addrinstructions intocopy_addrandload [copy]instructions to formcopy_addr [take]andload [take]instructions respectively. It does this even when the source of thecopy_addrorload [copy]is, rather than directly the address that isdestroy_addr'd, an access scope for that address (begin_access %addr).Previously, it would perform such folding even when the access scope was a
[read]. This is invalid because such a transformation makes the access scope no longer be a[read]. This is a problem because analyses expectbegin_accessinstructions to provide correct summaries. Furthermore, this is invalid in general because such an access scope may overlap with other read accesses to the same storage, and it is not allowed for a read access to overlap with a modify access.Here, when folding into a
copy_addrorload [copy]whose source is an access scope rather than directly the address beingdestroy_addr'd, it is checked that the access scope is not a[read].Scope: Affects optimized code.
Issue: rdar://154407327
Original PR: #82557
Risk: Low, this makes the optimization more conservative.
Testing: Added tests.
Reviewer: Erik Eckstein ( @eeckstein ), Andrew Trick ( @atrick )