Page MenuHomePhabricator

[lld] Add a flag to enable split machine functions for LTO.
Needs ReviewPublic

Authored by snehasish on Sep 21 2020, 12:48 PM.

Details

Reviewers
espindola
MaskRay
Summary

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 -
--lto-split-machine-functions.

Diff Detail

Event Timeline

snehasish created this revision.Sep 21 2020, 12:48 PM
Herald added a project: Restricted Project. · View Herald Transcript
snehasish requested review of this revision.Sep 21 2020, 12:48 PM

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.

lld/test/ELF/lto/split-machine-functions.ll
10

Check that the opposite occurs by default and with the "no" variant

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.

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?

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.

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.

Let me look into module flags a little bit and I'll come back to this patch once I have a better understanding. Thanks for the comments!