-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Some small deinit-barrier related optimizations #81159
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
Some small deinit-barrier related optimizations #81159
Conversation
@swift-ci test |
@swift-ci benchmark |
// We can ignore any memory writes in a program termination point, because it's not relevant | ||
// for the caller. But we need to consider memory reads, otherwise preceding memory writes | ||
// would be eliminated by dead-store-elimination in the caller. | ||
return GlobalEffects(memory: Memory(read: memory.read)) |
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.
Is it valid to have isDeinitBarrier
as false for such functions by default ?
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.
Yes, it should be valid. "Program termination point" functions are functions like fatalError
and exit
. They are not accessing objects (except strings).
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.
can you add that as a comment ?
@swift-ci test linux |
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
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
…fined in the same module This case was neglected. The fix can result in better side effect analysis, e.g. in the stdlib core module.
…, even if library evolution is turned on. This is possible because no copy of the function is emitted in the original module.
This API already existed in Swift, but not in the C++ SIL.
…he inlined function is not a deinit barrier. There is no need to do so. And this can enable other optimizations for non-lexical alloc-stacks.
b329a10
to
2fc32fb
Compare
@swift-ci smoke test |
@swift-ci smoke test macos |
@swift-ci smoke test windows |
This PR contains a few small optimization improvements which help to reduce the optimization limitations of lexical lifetimes and deinit barriers.
alloc_stack
if the inlined function is not a deinit barrier. There is no need to do so. And this can enable other optimizations for non-lexical alloc-stacks.@alwaysEmitIntoClient
functions, even if library evolution is turned on. This is possible because no copy of the function is emitted in the original module.