[AddressLowering] Create copy_addr after store. #62078
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
nate-chandler
force-pushed
the
opaque-values/1/20221112
branch
from
0b4dffa to
a9eaaa7
Compare
|
@swift-ci please test |
|
@swift-ci please test linux platform |
When rewriting a store, insert the copy_addr after it rather than before it. Previously, after the copy_addr is created, ``` alloc_stack %target_addr $Ty, var, name "something" ... copy_addr [take] %source_addr to [init] %target_addr store %instance to [init] %addr ``` when deleting the store, debug info salvaging may result in a debug_value instruction being created before the store, ``` alloc_stack %target_addr $Ty, var, name "something" ... copy_addr [take] %source_addr to [init] %target_addr debug_value %source_addr : $*Ty, var, name "something" store %instance to [init] %addr ``` using the %source_addr. If the created copy_addr is a [take], this results in the debug_value being a use-after-consume in the final SIL: ``` alloc_stack %target_addr $Ty, var, name "something" ... copy_addr [take] %source_addr to [init] %target_addr debug_value %source_addr : $*Ty, var, name "something" ``` Instead, now, the copy_addr is created after: ``` alloc_stack %target_addr $Ty, var, name "something" ... store %instance to [init] %addr copy_addr [take] %source_addr to [init] %target_addr ``` So when the debug_value instruction is created before the store during debug info salvaging ``` alloc_stack %target_addr $Ty, var, name "something" ... debug_value %source_addr : $*Ty, var, name "something" store %instance to [init] %addr copy_addr [take] %source_addr to [init] %target_addr ``` it is also before the newly added copy_addr. The result is that when the store is deleted, we have valid SIL: ``` alloc_stack %target_addr $Ty, var, name "something" ... debug_value %source_addr : $*Ty, var, name "something" copy_addr [take] %source_addr to [init] %target_addr
nate-chandler
force-pushed
the
opaque-values/1/20221112
branch
from
a9eaaa7 to
1023583
Compare
|
@swift-ci please smoke test |
|
LGTM but it makes me nervous about other places that may also salvage debug_info when deleting the original instruction. Any way to guard against that? |
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.
When rewriting a store, insert the copy_addr after it rather than before
it.
Previously, after the copy_addr is created,
when deleting the store, debug info salvaging may result in a
debug_value instruction being created before the store,
using the %source_addr. If the created copy_addr is a [take], this
results in the debug_value being a use-after-consume in the final SIL:
Instead, now, the copy_addr is created after:
So when the debug_value instruction is created before the store during
debug info salvaging
it is also before the newly added copy_addr. The result is that when
the store is deleted, we have valid SIL:
Based on #62074 .