You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Summary:
Currently Darwin distributed thin-lto builds produce a static archive from every apple_library target used as input to a link with `archive` actions, then unarchive them with `thin_lto_prepare` actions, passing the object files directly to the link.
Creating static archives only to unarchive them immediately is wasteful, we can save RE time, cache capacity and build time by just not creating the archives in the first place.
cxx_library rules (which apple_library is a wrapper on top of) produce either an [ObjectsLinkable](https://www.internalfb.com/code/fbsource/[1c6e9dd34c19f8d85fad642c437287dd873cb12e]/fbcode/buck2/prelude/linking/link_info.bzl?lines=107) or an [ArchiveLinkable](https://www.internalfb.com/code/fbsource/[1c6e9dd34c19f8d85fad642c437287dd873cb12e]/fbcode/buck2/prelude/linking/link_info.bzl?lines=87) linkable depending on configuration. Darwin links consume these linkables according to their traditional semantics (objects linkables eagerly, archive linkables lazily).
Until recently I thought GNU distributed thin-lto builds also suffer from this problem. But that's not true, GNU builds solve this archive unarchive problem by [always using lazy semantics unless the target is force loaded](https://www.internalfb.com/code/fbsource/[cab5aa83caca0cf7628f27945fc498439d2d5ebb]/fbcode/buck2/prelude/linking/link_info.bzl?lines=280), even for ObjectsLinkables, and [only producing ObjectsLinkables from cxx_library rules](https://www.internalfb.com/code/fbsource/[1c6e9dd34c19f8d85fad642c437287dd873cb12e]/fbcode/tools/build/buck/gen_modes.py?lines=1281) by setting `requires_objects` on their toolchain.
This means that their linker rule logic never consumes `ArchiveLinkables` unless unavoidable (ex: the Rust **compiler** always produces static archives for some reason). I would rather avoid this approach because it will be change in behavior for us, and it is unexpected imho. If the user sets `requires_objects` on their toolchain, and we turn around and pass every target to the linker as if they'd set `requires_archives` that seems a bit surprising to me.
In this change, we respect the semantics of the two linkables, but we add the ability to consume `ArchiveLinkables` more intelligently, operating on the object files directly and not creating the archive.
For now, we gate the change behind a config so we can measure improvements.
Reviewed By: rmaz
Differential Revision: D70101572
fbshipit-source-id: c793b1b3b7f809751d406a630d9393f8c4ff672e
# Without reading dynamic output, we cannot know if a given artifact represents bitcode to be included in LTO, or a native object file already (some inputs to a dthin-lto link are still native object files). We just include both the initial object (that may or may not be bitcode) and the produced bitcode file. dsym-util will only ever need one or the other, we just need to matieralize both.
0 commit comments