In Swift 5.2 we got the flag
-cross-module-optimization. What are the tradeoffs of turning this flag on for release builds? Why isn't there a dedicated option for it in the Xcode build settings?
In Swift 5.2 we got the flag
Xcode is private to Apple, and they don't comment on whys and wherefores for private tools. May show up in a future release, may not. If you want, you can file an enhancement request to Feedback Assistant.
Outside of the Xcode question I'm still curious about when this would make sense to use as well.
FWIW there's some explanation on what it does in the pull request that introduced it.
Yeah I'm not so curious about Xcode exactly, just more pointing out that this flag isn't really being promoted as something people should add, unlike wholemodule optimization for example. So, that points to there being tradeoffs, but if so, I'm not sure what they could be.
I tried it on a large project, and got crashes for a number of invocations like this one:
0. Running pass 'Module Verifier' on function '@"$s10MobiusCore10UnwrapEnum33_90C32D311123E16060FC94EF1F24C504LLO7extract4case4fromqd_0_Sgqd__qd_0_XE_qd__tr0_lFZ0L4HelpL_AGSaySSG_qd_0_tSgqd___tr0_0_lF23StorytellingFeatureImpl0P6EffectO_AL0B12PlayerActionOAnPTg5"' 0 swift 0x0000000105ac6615 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 37 1 swift 0x0000000105ac5615 llvm::sys::RunSignalHandlers() + 85 2 swift 0x0000000105ac6bcf SignalHandler(int) + 111 3 libsystem_platform.dylib 0x00007fff701735fd _sigtramp + 29 4 libsystem_platform.dylib 0x000000010dbb5b8d _sigtramp + 18446603343160944045 5 libsystem_c.dylib 0x00007fff70049808 abort + 120 6 swift 0x000000010162aaaf swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*)::$_1::__invoke(void*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, bool) + 1151 7 swift 0x0000000105a45a1a llvm::report_fatal_error(llvm::Twine const&, bool) + 234 8 swift 0x0000000105a45922 llvm::report_fatal_error(char const*, bool) + 50 9 swift 0x00000001059f2bcf (anonymous namespace)::VerifierLegacyPass::runOnFunction(llvm::Function&) + 111 10 swift 0x0000000105992abd llvm::FPPassManager::runOnFunction(llvm::Function&) + 925 11 swift 0x00000001059922e8 llvm::legacy::FunctionPassManagerImpl::run(llvm::Function&) + 104 12 swift 0x000000010599215b llvm::legacy::FunctionPassManager::run(llvm::Function&) + 91 13 swift 0x00000001019e9f51 swift::performLLVM(swift::IRGenOptions const&, swift::DiagnosticEngine&, llvm::sys::SmartMutex<false>*, llvm::GlobalVariable*, llvm::Module*, llvm::TargetMachine*, swift::version::Version const&, llvm::StringRef, swift::UnifiedStatsReporter*) + 5089 14 swift 0x00000001019f2451 (anonymous namespace)::LLVMCodeGenThreads::Thread::run() + 209 15 swift 0x00000001019f2379 (anonymous namespace)::LLVMCodeGenThreads::runThread(void*) + 9 16 libsystem_pthread.dylib 0x00007fff7017f109 _pthread_start + 148 17 libsystem_pthread.dylib 0x00007fff7017ab8b thread_start + 15
Crashes on our project as well.
@Erik_Eckstein can talk more about this, but my understanding is that he was hoping people would try it out and file bugs. We also haven't completed expanded it to serialize everything that we want it to (we need to be careful with code-size).
Is this intended to be an alternative to LTO?
-cross-module-optimization (CMO) is still in an "experimental" phase. Eventually we want to enable it by default (unless a module is compiled with
And yes, CMO has some tradeoffs. On the one hand it can improve performance significantly, e.g. if a module calls a generic function in another module. On the other hand this can lead to a code size increase.
The concept of CMO is comparable to LTO, but it's much more powerful, because it enables the swift (SIL) optimizer to optimize across modules (and not only the LLVM optimizer).
BTW, there is a (undocumented) Xcode build setting to enable CMO: SWIFT_CROSS_MODULE_OPTIMIZATION
It would be great if you could file bugs for those crashes - or for any other CMO-related problems.