-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Avoid introducing critical edges in SimplifyCFG #34362
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
@swift-ci test |
@swift-ci 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
|
Passes will end up resplitting them, forcing SimplifyCFG to continually rerun. Also, we want to allow SIL utilities to assume no critical edges, and avoid the need for several passes to internally split edges and modify the CFG for no reason.
All tests passed, but the performance regressions are still blocked on my fixes so semantic call inlining from a year ago. I'll see if I can get those fixes checked in first. |
17490d0
to
b69b349
Compare
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!
Do you know the reason for the benchmark regressions?
@eeckstein I've been investigating these regressions for the past week and attempting to stabilize the inliner/pipeline to avoid this sort of thing. They all look like arbitrary consequences of slight inlining changes. Unfortunately, any change I make to stabilize inlining requires other changes to avoid more regressions up to the point where the pass pipeline needs to be rewritten. Many of the regressions are in Data.init/append. The executed code does not change at all here. It's a 6-instruction loop in Sequence._copyContents that appears extremely sensitive to code placement. I see these benchmarks swing one way or the other whenever I make a small change to inlining costs. Instead of this PR, I have a series of smaller commits so it's easier to see where regressions first showed up. |
#34502 should avoid all the regressions |
Passes will end up resplitting them, forcing SimplifyCFG to
continually rerun.
Also, we want to allow SIL utilities to assume no critical edges, and
avoid the need for several passes to internally split edges and modify
the CFG for no reason.
Preparation for adding invariants that simplify working with OSSA form and opaque values.