-
Notifications
You must be signed in to change notification settings - Fork 57
Redo the Pass Manager #206
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
Sources/LLVM/PassPipeliner.swift
Outdated
.globalDCE, | ||
.deadArgElimination, | ||
.ipConstantPropagation, | ||
.ipscc: |
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.
I believe at least .functionAttrs should be here too.
51711ec
to
6c35b53
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.
Looking great!
@@ -106,8 +106,6 @@ public enum FunctionPass { | |||
case scalarReplAggregates | |||
/// Replace aggregates or pieces of aggregates with scalar SSA values. | |||
case scalarReplAggregatesSSA | |||
/// Tries to inline the fast path of library calls such as sqrt. | |||
case simplifyLibCalls |
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.
Why is this removed?
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.
The corresponding add pass function is a no-op as the pass has been removed.
All the SROA variants in the C API no longer make a difference.
This finally allows us to wrap passes that require additional parameters or configuration calls. In order to do this for internalize in particular, we have to do some heroic lifetime juggling.
⛵️ |
This thing was never correct. We mixed up Function passes and Module passes, and if you were unlucky enough to schedule both into the function pass manager then LLVM would probably crash.
Provide the interface we were shooting for here anyways in the form of a Swift-like pass pipeliner. You can freely mix module and function-level passes in the pipeliner, and we will schedule them the way LLVM would anyways (group the function passes, then run the module passes). There's bindings for LTO passes that never made it into a header that we could also wrap with this infrastructure.