-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[DCE] Don't delete instructions which consume escaping values. #80766
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
ae57199
to
e81523d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM Thank you!
Might want to move your test into the right commit.
I'm reminded that we still need to speed up findPointerEscape
When DCE deletes instructions as dead, if the instruction ends one of its operands lifetimes, it must insert a compensating lifetime end. When the def block of the value and the parent block of the instruction are different, it uses lifetime completion. Lifetime completion relies on complete liveness, which doesn't and can't exist for values with pointer escapes. The result is ending lifetimes too early. Avoid this scenario by marking such instructions live. In the fullness of time, it may be possible to track the deleted instruction's "location" even in the face of deletions of adjacent instructions and parent blocks and to insert the lifetime end at that location. rdar://149007151
e81523d
to
3ec9b26
Compare
@swift-ci please test |
@swift-ci please benchmark |
@swift-ci please test source compatibility |
@swift-ci please test windows platform |
This is the fix for #80731 |
When DCE deletes instructions as dead, if the instruction ends one of its operands lifetimes, it must insert a compensating lifetime end. When the def block of the value and the parent block of the instruction are different, it uses lifetime completion. Lifetime completion relies on complete liveness, which doesn't and can't exist for values with pointer escapes. The result is ending lifetimes too early.
Avoid this scenario by marking such instructions live.
In the fullness of time, it may be possible to track the deleted instruction's "location" even in the face of deletions of adjacent instructions and parent blocks and to insert the lifetime end at that location.
rdar://149007151