-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[SILOptimizer] Turn "is self-recursive" check into analysis #80236
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
The body of a function has to be re-analyzed for every call site of the function, which is very expensive and if the body is not changed would produce the same result. This takes about ~10% from swift-syntax overall build time in release configuration.
@swift-ci please test |
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, thanks!
@swift-ci apple silicon benchmark |
@swift-ci benchmark |
@swift-ci apple silicon benchmark |
Apple silicon benchmark fails with:
|
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.
Nice!
Thanks @xedin 😍 ! |
// Force the compiler to generate the destructor in this C++ file. | ||
// Otherwise it can happen that it is generated in a SwiftCompilerSources module | ||
// and that results in unresolved-symbols linker errors. | ||
IsSelfRecursive::~IsSelfRecursive() = default; |
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.
It's not just the destructor right, isn't this the way to convince clang to place the vtable in this TU?
The body of a function has to be re-analyzed for every call site of the function, which is very expensive and if the body is not changed would produce the same result.
This takes about ~10% from swift-syntax overall build time in release configuration.