-
Notifications
You must be signed in to change notification settings - Fork 10.6k
[LTO] Driver support for -lto_library flag #38264
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
This commit adds support for the -lto_library flag, allowing users to specify a custom LTO library on Darwin. This also fixes an issue where the default LTO library is used even if Driver is run from inside an alternate toolchain.
|
@swift-ci smoke test |
|
Thank you for your contribution! CI is currently limited to established contributors, so you'll need someone with Contributor access to be able to invoke CI. (I can do that for you) @swift-ci please smoke test Also, given that the swift-driver is now the default driver as of Xcode 13, could you also implement this in the swift-driver? It is structured somewhat similarly, so it shouldn't be too difficult now that you've done this work in the legacy driver. |
include/swift/Option/Options.td
Outdated
| Flags<[FrontendOption, NoInteractiveOption]>, | ||
| HelpText<"Specify the LTO type to either 'llvm-thin' or 'llvm-full'">; | ||
|
|
||
| def lto_library : Separate<["-"], "lto_library">, |
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.
Tiny nitpick: we usually prefer dashes to separate pieces of arguments, e.g. -lto-library.
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.
Ah, I see this is passed down to the linker. Still, I think we should promote linker-style arguments to Swift-style when we expose them from the Driver.
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.
Simple enough. Done 👍
I actually already have. As this is my first PR here I was waiting to see the feedback on this one before opening that one. |
Co-authored-by: Owen Voorhees <[email protected]>
|
@harlanhaskins Could you run the tests? |
|
@swift-ci please smoke test |
|
@owenv What is the procedure now that the tests are done? Anything else I should do? |
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.
Hey, sorry for the delay in reviewing this fully. This LGTM except for one place where I think might be checking the wrong path relative to swift. Once that's addressed (if needed), I think we can get this merged
| } else { | ||
| // Check for relative libLTO.dylib. This would be the expected behavior in an | ||
| // Xcode toolchain. | ||
| StringRef P = llvm::sys::path::parent_path(getDriver().getSwiftProgramPath()); |
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 think P is going to be <toolchain root>/usr/bin/ here, so we'll end up checking for libLTO in <toolchain root>/usr/bin/lib instead of <toolchain root>/usr/lib. I can't think of a good way to write a lit test for this unfortunately.
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.
Thanks for pointing this out. Fixed in latest commit.
|
@swift-ci please smoke test |
1 similar comment
|
@swift-ci please smoke test |
|
@swift-ci please test Windows |
This commit adds support for the -lto_library flag, allowing users to specify a custom LTO library on Darwin. This also fixes an issue where the default LTO library is used even if Driver is run from inside an alternate toolchain.
@gottesmm