With clang-cl gaining support for link-time optimization, we can now enable builds using LTO when using clang-cl and lld on Windows. To do this, we must not pass the -flto flag to the linker; lld-link does not understand it, but will perform LTO automatically when it encounters bitcode files. We also don't pass /Brepro when using LTO - the compiler doesn't generate object files for LTO, so passing the flag would only result in a warning about it being unused.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
This is cool! Does the lto/thinlto build actually work, tests passing etc?
cmake/modules/HandleLLVMOptions.cmake | ||
---|---|---|
416 ↗ | (On Diff #89316) | Maybe we should just make /Brepro be ignored with -flto in clang-cl instead of making users remove the flag? |
707 ↗ | (On Diff #89316) | Does this mean that if the user sets LLVM_ENABLE_LTO but forgets to set the build to use lld, we silently don't do LTO? Maybe we should error in the non-lld case instead? |
cmake/modules/HandleLLVMOptions.cmake | ||
---|---|---|
707 ↗ | (On Diff #89316) | Especially since otherwise the link will fail badly right? Preventing from generating an invalid configuration seems better to me. |
cmake/modules/HandleLLVMOptions.cmake | ||
---|---|---|
416 ↗ | (On Diff #89316) | I considered that, but it's not what clang (non-cl) does. I would be happy to implement that (for both?) if we feel that is the right way to go. For now, I decided to keep clang-cl consistent with clang and change the build configuration to not pass an assembler flag when we're not using the assembler. |
707 ↗ | (On Diff #89316) | Actually, using LLVM_ENABLE_LTO with MSVC's linker would fail with and without this change. Having said that, I agree it makes sense to think about how we can make this friendlier while we're making changes anyway. |
added error message for when unsupported combination of platform, LTO, and linker is used
cmake/modules/HandleLLVMOptions.cmake | ||
---|---|---|
709 ↗ | (On Diff #89935) | It shouldn't be. This is used to differentiate lld-link.exe from things like ld and lld, which do need the flag. It also matches link.exe without "lld-", which perhaps is a bit confusing. I can change it to look for lld-link, specifically, if folks feel that would be better. |
cmake/modules/HandleLLVMOptions.cmake | ||
---|---|---|
709 ↗ | (On Diff #89935) | Oh right, I was reading this as checking for link.exe, not that it might also be lld-link.exe :-) This is subtle, but I'm not sure how to make it better. |
refactored check for lld-link to be more explicit and less confusing
cmake/modules/HandleLLVMOptions.cmake | ||
---|---|---|
709 ↗ | (On Diff #89935) | I rewrote this to make the intent clearer, and also used the new way in the other places where we were checking for lld-link. |
llvm/trunk/cmake/modules/HandleLLVMOptions.cmake | ||
---|---|---|
717 | I don't understand this, this sounds suspicious to me. This is the flag we use to invoke *clang* for the linker step AFAIK, and it is up to clang to not pass the flag down to the lld-link job if not supported. | |
717 | For instance ld64 on macOS does not accept -flto either, but we still configure -flto here for the link stage invocation and leave up to the clang driver to handle the correct linker invocation. |
llvm/trunk/cmake/modules/HandleLLVMOptions.cmake | ||
---|---|---|
717 | On Windows, nobody invokes the compiler to do the link step, except people porting build systems from Unix. |
llvm/trunk/cmake/modules/HandleLLVMOptions.cmake | ||
---|---|---|
717 | Oh, OK, didn't know that! Nevermind then :) |
I don't understand this, this sounds suspicious to me. This is the flag we use to invoke *clang* for the linker step AFAIK, and it is up to clang to not pass the flag down to the lld-link job if not supported.