The machine function splitter is a codegen optimization pass which is
only available on X86 ELF and not turned on by default. To allow LTO
builds to take advantage of this optimization we add a flag -
Is it expected that the user will want to specify this only at link time and not during compile time? If it is normally specified in the compile step, you should consider adding it to the IR in some fashion (e.g. function attributes). The advantage is that the user doesn't need to pass different options for the LTO and non-LTO cases.
Check that the opposite occurs by default and with the "no" variant
Ideally we should only have to specify this once. However, using function attributes doesn't seem ideal since the pass will be scheduled and repeatedly invoked only to return without actually running the pass. It would be cleaner to marshal the codegen specific options from the compile invocation and restore them for the LTO step. There are a couple of other codegen options which would also benefit from this approach --lto-unique-basic-block-section-names, --lto-basic-block-sections=<value>. @mtrofin pointed out that -fembed-bitcode saves the invocation in .llvmcmd. A similar approach to stash codegen specific options always for LTO to pick up and enable might be less intrusive. However, this is a larger effort and for current LTO builds it would be nice to have a command line option to enable it. WDYT about this alternative?
If you want it determined at the module level, then you can use a module level flag metadata. See Module::addModuleFlag(). You would just need to figure out how to combine flags from different modules when merging them for *LTO. See ModFlagBehavior. The advantage is that you wouldn't need to check this for every function. But the disadvantage is that you lose the ability to mix and match different behavior for functions from different modules after any kind of LTO merging.