[pull] swiftwasm-release/5.4 from release/5.4 #2617
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
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
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. (cherry picked from commit 8948f75)
…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 <atrick@apple.com> 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. (cherry picked from commit 8b20984)
[5.4] Fix a SimplifyCFG typo and add a safeguard to prevent unbounded jump threading
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.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )