-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Add support for a mandatory-copy-propagation pass. #36245
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
Merged
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
It is currently disabled so this commit is NFC. MandatoryCopyPropagation canonicalizes all all OSSA lifetimes with either CopyValue or DestroyValue operations. While regular CopyPropagation only canonicalizes lifetimes with copies. This ensures that more lifetime program bugs are found in debug builds. Eventually, regular CopyPropagation will also canonicalize all lifetimes, but for now, we don't want to expose optimized code to more behavior change than necessary. Add frontend flags for developers to easily control copy propagation: -enable-copy-propagation: enables whatever form of copy propagation the current pipeline runs (mandatory-copy-propagation at -Onone, regular copy-propation at -O). -disable-copy-propagation: similarly disables any form of copy propagation in the current pipelien. To control a specific variant of the passes, use -Xllvm -disable-pass=mandatory-copy-propagation or -Xllvm -disable-pass=copy-propagation instead. The meaning of these flags will stay the same as we adjust the defaults. Soon mandatory-copy-propagation will be enabled by default. There are two reasons to do this, both related to predictable behavior across Debug and Release builds. 1. Shortening object lifetimes can cause observable changes in program behavior in the presense of weak/unowned reference and deinitializer side effects. 2. Programmers need to know reliably whether a given code pattern will copy the storage for copy-on-write types (Array, Set). Eliminating the "unexpected" copies the same way at -Onone and -O both makes debugging tractable and provides assurance that the code isn't relying on the luck of the optimizer in a particular compiler release.
This bleeds into the implementation where "guaranteed" is used everywhere to talk about optimization of guaranteed values. We need to use mandatory to indicate we're talking about the pass pipeline.
-enable-copy-propagation: enables whatever form of copy propagation the current pipeline runs (mandatory-copy-propagation at -Onone, regular copy-propation at -O). -disable-copy-propagation: similarly disables any form of copy propagation in the current pipelien.
Otherwise the verifier will fail on trivial cases like this: sil hidden [ossa] @testassign : $@convention(thin) <T> (@inout T, @in T) -> () { bb0(%0 : $*T, %1 : @owned $T): store %1 to [assign] %0 : $*T %3 = tuple () return %3 : $() } SIL memory lifetime failure in @testassign: memory is initialized at function return but shouldn't memory location: %1 = argument of bb0 : $T
Move opaque-value tests into copy_propagation_opaque.sil.
@swift-ci test |
@swift-ci smoke test |
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.
It is currently disabled so this commit is NFC.
MandatoryCopyPropagation canonicalizes all all OSSA lifetimes with
either CopyValue or DestroyValue operations. While regular
CopyPropagation only canonicalizes lifetimes with copies. This ensures
that more lifetime program bugs are found in debug builds. Eventually,
regular CopyPropagation will also canonicalize all lifetimes, but for
now, we don't want to expose optimized code to more behavior change
than necessary.
Add frontend flags for developers to easily control copy propagation:
-enable-copy-propagation: enables whatever form of copy propagation the current pipeline runs (mandatory-copy-propagation at -Onone, regular copy-propation at -O).
-disable-copy-propagation: similarly disables any form of copy
propagation in the current pipelien.
To control a specific variant of the passes, use
-Xllvm -disable-pass=mandatory-copy-propagation
or -Xllvm -disable-pass=copy-propagation instead.
The meaning of these flags will stay the same as we adjust the
defaults. Soon mandatory-copy-propagation will be enabled by
default. There are two reasons to do this, both related to predictable
behavior across Debug and Release builds.
Shortening object lifetimes can cause observable changes in program
behavior in the presense of weak/unowned reference and
deinitializer side effects.
Programmers need to know reliably whether a given code pattern will
copy the storage for copy-on-write types (Array, Set). Eliminating
the "unexpected" copies the same way at -Onone and -O both makes
debugging tractable and provides assurance that the code isn't
relying on the luck of the optimizer in a particular compiler
release.