-
Notifications
You must be signed in to change notification settings - Fork 10.4k
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
[Driver][Frontend] Introduce load-pass-plugin
option
#68985
[Driver][Frontend] Introduce load-pass-plugin
option
#68985
Conversation
Please, let me know if anything needs to be improved as far as style conventions et alia is concerned, I'd be happy to do so. |
(cc/ @DougGregor) |
09d9fde
to
2293235
Compare
Gentle ping. Any feedback or suggestions would be duly appreciated. Alongside this, I believe the option should be added as part of Options.swift as well. May that be the case? (cc/ @DougGregor, @rintaro). |
Hey, this may not be getting much attention because the internal driver (this one) is considered legacy. The default driver as of Xcode 13 swift-driver. You might have better luck over there. Note: I'm not affiliated with the Swift project in any way. Just a guy who'd love to see this merged |
There was some discussion on this previously in: The driver and frontend pieces are separate and yes, proper driver support would mean adding the logic in https://github.com/apple/swift-driver. Legacy (C++-based) driver support being optional/discouraged. @lhames @aschwaighofer can comment better on the architecture of loading such passes in IRGen. |
Thanks a lot to both for the helpful insights. Support in the new swift-driver should be addressed by swiftlang/swift-driver#1472. The implementation should aim to ensure a clear separation between the driver and the frontend. Also, thanks for sharing #38017, was not aware of this. Reviewed the discussion there carefully, it was very informative. |
2293235
to
177dc53
Compare
Fixed conflicts by rebasing to main, and changed test library type from |
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 way this patch proposes to load the plugin pass in IRGen looks good. It is exactly what we do in Clang and Flang, and what the documentation recommends.
} else { | ||
diagnoseSync(Diags, DiagMutex, SourceLoc(), | ||
diag::unable_to_load_pass_plugin, PluginFile, | ||
toString(PassPlugin.takeError())); |
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 wonder if the diagnostic handling should remain in performLLVM()
. Passing Diags
and DiagMutex
to performLLVMOptimizations()
seems a bit unfortunate. We could instead just return the llvm::Error
from here and let the callers take care of it. That would change the return type of the function. A lot of code in include/swift is using llvm::Error
already, but I am not sure what the conventions are in Swift. @lhames What do you think?
Gentle ping (cc/ @lhames). |
Just wanted to express support for this here as it also helps with adding plugins for AD |
Also expressing support for this! |
177dc53
to
7055ddf
Compare
Rebased to main, dropped unittest in |
7055ddf
to
564940c
Compare
@lhames, @airspeedswift Gentle ping. Any chance of this getting reviewed? |
Kind ping (maybe cc/ @adrian-prantl). |
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 with a couple of minor comments inside.
564940c
to
bfc69de
Compare
@adrian-prantl Addressed comments and rebased to main, thank you for reviewing this! |
@swift-ci test |
bfc69de
to
f4d021f
Compare
Rebased to main, opened sister PR @ swiftlang/llvm-project#8678, reflecting changes (not sure if we should have targeted a different branch instead). |
@adrian-prantl Kind ping on this, CI was previously failing. |
f4d021f
to
0489398
Compare
Rebased to main (fixed conflicts), swiftlang/llvm-project#8678 PR rebased to |
I assume this should be tested with:
|
The macOS failure is:
edit: should have been fixed by #76344 |
@JDevlieghere This will be affected by the rebranch isn't it? Any chance it can land before? |
@adrian-prantl @JDevlieghere is this good to merge? |
I don't have any further concerns with this patch. |
Allow dynamic loading of LLVM passes via `load-pass-plugin` option passed to the Swift compiler driver.
0489398
to
377c03f
Compare
Rebased to main, fixed conflicts (to be tested again as above otherwise CI fails), kind ping for merging this. |
@swift-ci test |
Thanks, the other two PRs (swiftlang/llvm-project#8678, swiftlang/swift-driver#1472) are also required for the CI to pass. |
@antoniofrighetto Can you put up a PR against |
Done at swiftlang/llvm-project#9586, thanks. |
Kind ping (before other rebases conflicts pop up :P) |
@antoniofrighetto @aschwaighofer |
Allow dynamic loading of LLVM passes via
load-pass-plugin
option passed to the Swift compiler driver, similarly to current Apple Clang-fpass-plugin
option.Previous discussion: https://forums.swift.org/t/load-external-llvm-pass-plugins-via-swift-frontend/67596