-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[inliner] Treat inline_always as meaning truly inline_always even in … #20589
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
[inliner] Treat inline_always as meaning truly inline_always even in … #20589
Conversation
…situations where we have large caller CFGs. Currently if a caller is > 400 blocks, the inliner bails out of finding inlinable targets. This is incorrect behavior for inline always functions. In such cases, we should continue inlining inline always functions and skip any functions that are not inline always. rdar://45976860
I am going to add some tests before I commit this. Just want to do some initial testing/benchmarking. |
@swift-ci test |
@swift-ci benchmark |
@swift-ci test compiler performance |
Build comment file: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
|
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 we know why the stdlib is 5% bigger with this? This is worth taking even if we have to suffer that regression, but I'm thinking that this might expose some needless code bloat. |
I didn't look into it. @airspeedswift and @eeckstein talked about this and decided we were ok taking the code-size hit. |
Also, I took a look at the overall code-size per project. Here is a % change. You'll see that almost all of the projects actually /decrease/ in size (i.e. left is good, right is bad): |
To be clear by per project, I mean per source compatibility project. |
…situations where we have large caller CFGs.
Currently if a caller is > 400 blocks, the inliner bails out of finding
inlinable targets. This is incorrect behavior for inline always functions. In
such cases, we should continue inlining inline always functions and skip any
functions that are not inline always.
rdar://45976860