-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[ownership] Move lowering past SILCombine and right before the inliner. #35802
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
[ownership] Move lowering past SILCombine and right before the inliner. #35802
Conversation
@swift-ci test |
@swift-ci test source compatibility |
@swift-ci benchmark |
…unchecked_take_enum_data_addr + load -> load + unchecked_enum_data. We must make sure the new load is inserted where the old load was instead of inserting it at the unchecked_take_enum_data_addr, since the unchecked_take_enum_data_addr may be in a different block from old load /and/ old load may not post-dominate that point. This was just a thinko.
… run. I am doing this to separate the perf effect of moving ownership past the inliner with this earlier stuff.
da69a5f
to
5ab8022
Compare
@swift-ci test |
@swift-ci benchmark |
@swift-ci test source compatibility |
@swift-ci smoke test compiler performance |
Just to note, current source compat release failures:
And the debug has had issues over the past bit just building. Just going to make sure I didn't make this worse. |
Performance: -O
Code size: -OPerformance: -Osize
Code size: -OsizePerformance: -Onone
Code size: -swiftlibsHow 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
|
@swift-ci benchmark |
Release source compat failed due to a weird module map issue. |
Not this PR for sure. |
Debug one hit the same thing:
|
Performance: -O
Code size: -OPerformance: -Osize
Code size: -OsizePerformance: -Onone
Code size: -swiftlibsHow 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
|
Compilation-performance test failed |
This one I happen to know something about: |
I don't think the perf changes are real. Going to run again. |
@swift-ci benchmark |
Not real in the sense that the regressions are changing each time suggesting noise. |
Performance: -O
Code size: -OPerformance: -Osize
Code size: -OsizePerformance: -Onone
Code size: -swiftlibsHow 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
|
If you look at the 3 groups of results for -O, -Osize every time the regressions are changing suggesting they are noise. Consider for -O:
And for -Osize:
|
Merging! |
Just a good place to test this functionality separately from the inliner.
NOTE: There is currently a draft since there is one commit I am going to get in via a different PR. This PR I am going to use initially for testing and maybe once that other commit lands, rebase on top and just move the passes as an independent change into the tree.