mirror of
https://github.com/apple/swift.git
synced 2026-02-27 18:26:24 +01:00
b37511ef42
This is second version of #85621 which was reverted in #85794 because
the result of `_compute_lto_flag` was used as a boolean in some
contexts.
The differences from the original is that `_compute_lto_flag` is split
into a second function `_is_lto_enabled` which provides an actual
boolean for when LTO is enabled, and the half dozen usages of
`_compute_lto_flag` have been audited for using `_compute_lto_flag`
without considering the return value a boolean, or using the new
`_is_lto_enabled` as a proper boolean. A small clean up of commented out
code is performed (probably just a forgetten clean up from #66077).
The changes have been verified by compiling with
`SWIFT_STDLIB_ENABLE_LTO=thin` and
`SWIFT_STDLIB_BUILD_TYPE=RelWithDebInfo`, and checking the resulting
flags for building the stdlib include both `-flto=thin` and
`-gline-tables-only`, while the Swift tools include `-fno-lto` instead.
The following is the original commit message, which explains why this
change is interesting:
---
When compiling Swift as an LLVM external project (not the non-unified
workflow from the build-script), if one tries to enable LTO for LLVM
projects it will end up affecting Swift and the Swift standard library,
even if the options `SWIFT_TOOLS_ENABLE_LTO` and
`SWIFT_STDLIB_ENABLE_LTO` are disabled or using their default values,
because [HandleLLVMOptions] modifies the `CMAKE_C/CXX_FLAGS` globally.
By setting `-fno-lto` explicitly when those options are disabled or
using their default values, the options from `CMAKE_C/CXX_FLAGS` are
overriden, and the `SWIFT_*_ENABLE_LTO` controls the usage or not of LTO
optimizations and the presence of bitcode in the object files.
[HandleLLVMOptions]:
b58b2a34d5/llvm/cmake/modules/HandleLLVMOptions.cmake (L1278-L1310)