Add a safeguard to SimplifyCFG tryJumpThreading to avoid infinite loop peeling #35608
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
Fixes rdar://73357726 ([SR-14068]: Compiling with optimisation runs indefinitely for grpc-swift) The root cause of this problem is that SimplifyCFG::tryJumpThreading jump threads into loops, effectively peeling loops. This is not the right way to implement loop peeling. That belongs in a loop optimization pass. There's is simply no sane way to control jump threading if it is allowed across loop boundaries, both from the standpoint of requiring optimizations to terminate and from the standpoint of reducing senseless code bloat. SimplifyCFG does have a mechanism to avoid jump-threading into loop in most cases. That mechanism would actually prevent the infinite loop peeling in this particular case if it were implemented correctly. But the original implementation circa 2014 appears to have a typo. This commit fixes that obvious bug. I do not think it's a sufficient to ensure we never see the bad behavior. I will file separate bugs for the broader issue. This bad behavior was exposed incidentally by splitting critical edges. Without edge splitting, SimplifyCFG::simplifyBlocks only performs "jump threading" once, creating a critical edge to the loop header. Because simplifyBlocks works under the assumption that there are no critical edges, it never attempts to perform jump threading again. In other words, the presence of the critical edge "breaks" the optimization, preventing it from continuing as intended. With edge splitting, the simplifyBlocks worklist performs "jump threading" followed by "jump to trampoline" removal, which creates a new loop-back edge to the original loop header. This is fine. However, simplifyBlocks iteratively attempts all optimizations up to a fix point and it does not stop at loop headers! So, splitting the critical edge causes simplifyBlocks to work as intended, which leads to infinite loop peeling. The end result is an infinite sequence of nested loops. Each peeled iteration is actually within the parent loop.
…p peeling rdar://73644659 (Add a safeguard to SimplifyCFG tryJumpThreading to avoid infinite loop peeling) A case of infinite loop peeling was exposed recently: ([SR-14068]: Compiling with optimisation runs indefinitely for grpc-swift) It was trivially fixed here: --- commit 8948f75 (HEAD -> fix-simplifycfg-tramp, public/fix-simplifycfg-tramp) Author: Andrew Trick <[email protected]> Date: Tue Jan 26 17:02:37 2021 Fix a SimplifyCFG typo that leads to unbounded optimization --- However, that fix isn't a strong guarantee against this behavior. The obvious complete fix is that jump-threading should not affect loop structure. But changing that requires a performance investigation. In the meantime this change introduces a simple mechanism that guarantees that a loop header is not repeatedly cloned. This safeguard is worthwhile because jump-threading across loop boundaries is kicking in more frequently now the critical edges are being split within SimplifyCFG. Note that it is both necessary and desirable to split critical edges between transformations so that SIL remains in a valid state. That allows other code in SimplifyCFG to call arbitrary SIL utilities, allows verifying SimplifyCFG by running verification between transformation, and simplifies the patters that SimplifyCFG itself needs to consider.
|
@swift-ci 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.
A case of infinite loop peeling was exposed recently:
([SR-14068]: Compiling with optimisation runs indefinitely for grpc-swift)
It was trivially fixed here:
commit 8948f75 (HEAD -> fix-simplifycfg-tramp, public/fix-simplifycfg-tramp)
Author: Andrew Trick [email protected]
Date: Tue Jan 26 17:02:37 2021
Fix a SimplifyCFG typo that leads to unbounded optimization
However, that fix isn't a strong guarantee against this behavior. The
obvious complete fix is that jump-threading should not affect loop
structure. But changing that requires a performance investigation. In
the meantime this change introduces a simple mechanism that guarantees
that a loop header is not repeatedly cloned.
This safeguard is worthwhile because jump-threading across loop
boundaries is kicking in more frequently now the critical edges are
being split within SimplifyCFG.
Note that it is both necessary and desirable to split critical edges
between transformations so that SIL remains in a valid state. That
allows other code in SimplifyCFG to call arbitrary SIL utilities,
allows verifying SimplifyCFG by running verification between
transformation, and simplifies the patters that SimplifyCFG itself
needs to consider.
rdar://73644659 (Add a safeguard to SimplifyCFG tryJumpThreading to avoid infinite loop peeling)