-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Handle begin_apply in TempRVO #31063
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
A tempobj passed to begin_apply instruction and cannot be modified by it (is guaranteed and doesn't alias with other inout args) can be optimzed away.
@swift-ci please test |
@swift-ci benchmark |
Build failed before running benchmark. |
@swift-ci please benchmark |
Performance: -O
Code size: -O
Performance: -Osize
Code size: -Osize
Performance: -Onone
Code size: -swiftlibs
How to read the dataThe tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.If you see any unexpected regressions, you should consider fixing the Noise: Sometimes the performance results (not code size!) contain false Hardware Overview
|
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.
Thanks for fixing this. But remember that a begin_apply operand is used at the point of the end_apply. So the end_apply needs to be considered the use-point for things like checkNoSourceModification.
@swift-ci test |
Build failed |
Build failed |
@swift-ci test linux |
@swift-ci please test |
Build failed |
Build failed |
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
* Handle begin_apply in TempRVO A tempobj passed to begin_apply instruction and cannot be modified by it (is guaranteed and doesn't alias with other inout args) can be optimzed away.
A tempobj passed to begin_apply instruction and cannot be modified by it
(is guaranteed and doesn't alias with other inout args) has potential to be optimized
away.