[lld-macho] Handle filename being passed in -lto_object_path

Clang passes a filename rather than a directory in -lto_object_path when
using FullLTO. Previously, it was always treated it as a directo

[lld-macho] Handle filename being passed in -lto_object_path

Clang passes a filename rather than a directory in -lto_object_path when
using FullLTO. Previously, it was always treated it as a directory, so
lld would crash when it attempted to create temporary files inside it.

Fixes #54805

Differential Revision: https://reviews.llvm.org/D129705

show more ...

[lld-macho] Make `--icf=safe` work with LTO

Just matter of enabling the config option.

(Also changed the platform of the input test file to macOS, since that's
the default that we specify in the `%

[lld-macho] Make `--icf=safe` work with LTO

Just matter of enabling the config option.

(Also changed the platform of the input test file to macOS, since that's
the default that we specify in the `%lld` substitution. The conflict was
causing errors when linking with LTO.)

Reviewed By: #lld-macho, thakis

Differential Revision: https://reviews.llvm.org/D127600

show more ...

[lld] Remove support for legacy pass manager

This removes options for performing LTO with the legacy pass
manager in LLD. Options that explicitly enable the new pass manager
are retained as no-ops.

[lld] Remove support for legacy pass manager

This removes options for performing LTO with the legacy pass
manager in LLD. Options that explicitly enable the new pass manager
are retained as no-ops.

Differential Revision: https://reviews.llvm.org/D123219

show more ...

[lld-macho] Set FinalDefinitionInLinkageUnit on most LTO externs

Since Mach-O has a two-level namespace (unlike ELF), we can usually set
this property to true.

(I believe this setting is only avail

[lld-macho] Set FinalDefinitionInLinkageUnit on most LTO externs

Since Mach-O has a two-level namespace (unlike ELF), we can usually set
this property to true.

(I believe this setting is only available in the new LTO backend, so I
can't really use ld64 / libLTO's behavior as a reference here... I'm
just doing what I think is correct.)

See {D119294} for the work done to calculate the `interposable` used in
this diff.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D119506

show more ...

[lld-macho] Unset ExportDynamic where possible for LTO

By unsetting this property, we are now able to internalize more symbols
during LTO. I compared the output of `-save-temps` for both LLD and
ld6

[lld-macho] Unset ExportDynamic where possible for LTO

By unsetting this property, we are now able to internalize more symbols
during LTO. I compared the output of `-save-temps` for both LLD and
ld64, and we now match ld64's behavior as far as `lto-internalize.ll` is
concerned.

(Thanks @smeenai for working on an initial version of this diff!)

Fixes https://github.com/llvm/llvm-project/issues/50574.

Reviewed By: #lld-macho, thakis

Differential Revision: https://reviews.llvm.org/D119372

show more ...

Re-land [LLD] Remove global state in lldCommon

Move all variables at file-scope or function-static-scope into a hosting structure (lld::CommonLinkerContext) that lives at lldMain()-scope. Drivers wi

Re-land [LLD] Remove global state in lldCommon

Move all variables at file-scope or function-static-scope into a hosting structure (lld::CommonLinkerContext) that lives at lldMain()-scope. Drivers will inherit from this structure and add their own global state, in the same way as for the existing COFFLinkerContext.

See discussion in https://lists.llvm.org/pipermail/llvm-dev/2021-June/151184.html

The previous land f860fe362282ed69b9d4503a20e5d20b9a041189 caused issues in https://lab.llvm.org/buildbot/#/builders/123/builds/8383, fixed by 22ee510dac9440a74b2e5b3fe3ff13ccdbf55af3.

Differential Revision: https://reviews.llvm.org/D108850

show more ...

Revert [LLD] Remove global state in lldCommon

It seems to be causing issues on https://lab.llvm.org/buildbot/#/builders/123/builds/8383

[LLD] Remove global state in lldCommon

Move all variables at file-scope or function-static-scope into a hosting structure (lld::CommonLinkerContext) that lives at lldMain()-scope. Drivers will inher

[LLD] Remove global state in lldCommon

Move all variables at file-scope or function-static-scope into a hosting structure (lld::CommonLinkerContext) that lives at lldMain()-scope. Drivers will inherit from this structure and add their own global state, in the same way as for the existing COFFLinkerContext.

See discussion in https://lists.llvm.org/pipermail/llvm-dev/2021-June/151184.html

Differential Revision: https://reviews.llvm.org/D108850

show more ...

[Support] Improve Caching conformance with Support library behavior

This diff makes several amendments to the local file caching mechanism
which was migrated from ThinLTO to Support in
rGe678c511771

[Support] Improve Caching conformance with Support library behavior

This diff makes several amendments to the local file caching mechanism
which was migrated from ThinLTO to Support in
rGe678c51177102845c93529d457b020f969125373 in response to follow-up
discussion on that commit.

Patch By: noajshu

Differential Revision: https://reviews.llvm.org/D113080

show more ...

[Support][ThinLTO] Move ThinLTO caching to LLVM Support library

We would like to move ThinLTO’s battle-tested file caching mechanism to
the LLVM Support library so that we can use it elsewhere in LL

[Support][ThinLTO] Move ThinLTO caching to LLVM Support library

We would like to move ThinLTO’s battle-tested file caching mechanism to
the LLVM Support library so that we can use it elsewhere in LLVM.

Patch By: noajshu

Differential Revision: https://reviews.llvm.org/D111371

show more ...

Revert "[Support][ThinLTO] Move ThinLTO caching to LLVM Support library"

This reverts commit 92b8cc52bbc8194f2cd6a5f742b874969421afca since
it broke the gold plugin.

[Support][ThinLTO] Move ThinLTO caching to LLVM Support library

We would like to move ThinLTO’s battle-tested file caching mechanism to
the LLVM Support library so that we can use it elsewhere in LL

[Support][ThinLTO] Move ThinLTO caching to LLVM Support library

We would like to move ThinLTO’s battle-tested file caching mechanism to
the LLVM Support library so that we can use it elsewhere in LLVM.

Patch By: noajshu

Differential Revision: https://reviews.llvm.org/D111371

show more ...

[lld-macho] Initialize LTO backend with diagnostic handler

Failing to do so results in `std::bad_function_call` being
thrown when a pass tries to emit a diagnostic.

I've copied the relevant test ov

[lld-macho] Initialize LTO backend with diagnostic handler

Failing to do so results in `std::bad_function_call` being
thrown when a pass tries to emit a diagnostic.

I've copied the relevant test over from LLD-ELF's test suite.

Reviewed By: #lld-macho, thevinster

Differential Revision: https://reviews.llvm.org/D109274

show more ...

[lld-macho] Add LTO cache support

This adds support for the lld-only `--thinlto-cache-policy` option, as well as
implementations for ld64's `-cache_path_lto`, `-prune_interval_lto`,
`-prune_after_lt

[lld-macho] Add LTO cache support

This adds support for the lld-only `--thinlto-cache-policy` option, as well as
implementations for ld64's `-cache_path_lto`, `-prune_interval_lto`,
`-prune_after_lto`, and `-max_relative_cache_size_lto`.

Test is adapted from lld/test/ELF/lto/cache.ll

Differential Revision: https://reviews.llvm.org/D105922

show more ...

[lld/mac] Partially implement -export_dynamic

This implements the part of -export_dynamic that adds external
symbols as dead strip roots even for executables.

It does not yet implement the effect -

[lld/mac] Partially implement -export_dynamic

This implements the part of -export_dynamic that adds external
symbols as dead strip roots even for executables.

It does not yet implement the effect -export_dynamic has for LTO.
I tried just replacing `config->outputType != MH_EXECUTE` with
`(config->outputType != MH_EXECUTE || config->exportDynamic)` in
LTO.cpp, but then local symbols make it into the symbol table too,
which is too much (and also doesn't match ld64). So punt on this
for now until I understand it better.
(D91583 may or may not be related too).

Differential Revision: https://reviews.llvm.org/D105482

show more ...

[lld-macho] Add support for LTO optimization level

Everything (including test) modified from ELF/COFF. Using the same syntax
(--lto-O3, etc) as ELF.

Differential Revision: https://reviews.llvm.org/

[lld-macho] Add support for LTO optimization level

Everything (including test) modified from ELF/COFF. Using the same syntax
(--lto-O3, etc) as ELF.

Differential Revision: https://reviews.llvm.org/D105223

show more ...

[lld-macho][nfc] Add accessors for commonly-used PlatformInfo fields

As discussed here: https://reviews.llvm.org/D100523#inline-951543

Reviewed By: #lld-macho, thakis, alexshap

Differential Revisi

[lld-macho][nfc] Add accessors for commonly-used PlatformInfo fields

As discussed here: https://reviews.llvm.org/D100523#inline-951543

Reviewed By: #lld-macho, thakis, alexshap

Differential Revision: https://reviews.llvm.org/D100978

show more ...

[lld][MachO] Add support for LC_VERSION_MIN_* load commands

This diff adds initial support for the legacy LC_VERSION_MIN_* load commands.

Test plan: make check-lld-macho

Differential revision: htt

[lld][MachO] Add support for LC_VERSION_MIN_* load commands

This diff adds initial support for the legacy LC_VERSION_MIN_* load commands.

Test plan: make check-lld-macho

Differential revision: https://reviews.llvm.org/D100523

show more ...

[lld-macho] LTO: Unset VisibleToRegularObj where possible

This allows LLVM's LTO to internalize symbols that are not referenced
directly by regular objects. Naturally, this means we need to track
wh

[lld-macho] LTO: Unset VisibleToRegularObj where possible

This allows LLVM's LTO to internalize symbols that are not referenced
directly by regular objects. Naturally, this means we need to track
which symbols are referenced by regular objects. The approach taken here
is similar to LLD-COFF's: like the COFF port, we extend
`SymbolTable::insert()` to set the isVisibleToRegularObj bit. (LLD-ELF
relies on the Symbol constructor and `Symbol::mergeProperties()`, but
the Mach-O port does not have a `mergeProperties()` equivalent.)

From what I can tell, ld64 (which uses libLTO) doesn't do this
optimization at all. I'm not even sure libLTO provides a way to do this.
Not having ld64's behavior as a reference implementation is unfortunate;
instead, I am relying on LLD-ELF/COFF's behavior as references while
erring on the conservative side. In particular, LLD-MachO will only do
this optimization for executables right now.

We also don't attempt it when `-flat_namespace` is used -- otherwise
we'd need scan the symbol table to find matches for every un-namespaced
symbol reference, which is expensive.

internalize.ll is based off the LLD-ELF tests `internalize-basic.ll` and
`internalize-undef.ll`. Looks like @davide added some of LLD-ELF's internalize
tests, so adding him as a reviewer...

Reviewed By: #lld-macho, gkm

Differential Revision: https://reviews.llvm.org/D99105

show more ...

[lld-macho] Support --thinlto-jobs

The test is loosely based off LLD-ELF's `thinlto.ll`. However, I
found that test questionable because the the -save_temps behavior it
checks for is identical regar

[lld-macho] Support --thinlto-jobs

The test is loosely based off LLD-ELF's `thinlto.ll`. However, I
found that test questionable because the the -save_temps behavior it
checks for is identical regardless of whether we are running in single-
or multi-threaded mode. I tried writing a test based on `--time-trace`
but couldn't get it to run deterministically... so I've opted to just
skip checking that behavior for now.

Reviewed By: #lld-macho, gkm

Differential Revision: https://reviews.llvm.org/D99356

show more ...

[lld-macho][nfc] Refactor in preparation for 32-bit support

The main challenge was handling the different on-disk structures (e.g.
`mach_header` vs `mach_header_64`). I tried to strike a balance bet

[lld-macho][nfc] Refactor in preparation for 32-bit support

The main challenge was handling the different on-disk structures (e.g.
`mach_header` vs `mach_header_64`). I tried to strike a balance between
sprinkling `target->wordSize == 8` checks everywhere (branchy = slow, and ugly)
and templatizing everything (causes code bloat, also ugly). I think I struck a
decent balance by judicious use of type erasure.

Note that LLD-ELF has a similar architecture, though it seems to use more templating.

Linking chromium_framework takes about the same time before and after this
change:

N Min Max Median Avg Stddev
x 20 4.52 4.67 4.595 4.5945 0.044423204
+ 20 4.5 4.71 4.575 4.582 0.056344803
No difference proven at 95.0% confidence

Reviewed By: #lld-macho, oontvoo

Differential Revision: https://reviews.llvm.org/D99633

show more ...

[lld-macho] Add time tracing for LTO

The test is similar to the one used for LLD-ELF.

Differential Revision: https://reviews.llvm.org/D99318

[lld-macho][NFC] Drop unnecessary braces around simple if/for bodies

Minor cleanup

Differential Revision: https://reviews.llvm.org/D98758

[lld-macho][NFC] when reasonable, replace auto keyword with type names

lld policy discourages `auto`. Replace it with a type name whenever reasonable. Retain `auto` to avoid ...
* redundancy, as for

[lld-macho][NFC] when reasonable, replace auto keyword with type names

lld policy discourages `auto`. Replace it with a type name whenever reasonable. Retain `auto` to avoid ...
* redundancy, as for decls such as `auto *t = mumble_cast<TYPE *>` or similar that specifies the result type on the RHS
* verbosity, as for iterators
* gratuitous suffering, as for lambdas

Along the way, add `const` when appropriate.

Note: a future diff will ...
* add more `const` qualifiers
* remove `opt::` when we are already `using llvm::opt`

Differential Revision: https://reviews.llvm.org/D98313

show more ...

[lld-macho] Filter TAPI re-exports by target

Previously, we were loading re-exports without checking whether
they were compatible with our target. Prior to {D97209}, it meant that
we were defining d

[lld-macho] Filter TAPI re-exports by target

Previously, we were loading re-exports without checking whether
they were compatible with our target. Prior to {D97209}, it meant that
we were defining dylib symbols that were invalid -- usually a silent
failure unless our binary actually used them. D97209 exposed this as an
explicit error.

Along the way, I've extended our TAPI compatibility check to cover the
platform as well, instead of just checking the arch. To this end, I've
replaced MachO::Architecture with MachO::Target in our Config struct.

Reviewed By: #lld-macho, oontvoo

Differential Revision: https://reviews.llvm.org/D97867

show more ...