[lld-macho] Fold cfstrings with --deduplicate-literals

Similar to cstrings ld64 always deduplicates cfstrings. This was already
being done when enabling ICF, but for debug builds you may want to fli

[lld-macho] Fold cfstrings with --deduplicate-literals

Similar to cstrings ld64 always deduplicates cfstrings. This was already
being done when enabling ICF, but for debug builds you may want to flip
this on if you cannot eliminate your instances of this, so this change
makes --deduplicate-literals also apply to cfstrings.

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

show more ...

[lld-macho] Read in new addrsig format

The new format uses symbol relocations, as described in {D127637}.

Reviewed By: #lld-macho, alx32

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

[lld-macho] Support folding of functions with identical LSDAs

To do this, we need to slice away the LSDA pointer, just like we are
slicing away the functionAddress pointer.

No observable difference

[lld-macho] Support folding of functions with identical LSDAs

To do this, we need to slice away the LSDA pointer, just like we are
slicing away the functionAddress pointer.

No observable difference in perf on chromium_framework:

base diff difference (95% CI)
sys_time 1.769 ± 0.068 1.761 ± 0.065 [ -2.7% .. +1.8%]
user_time 9.517 ± 0.110 9.528 ± 0.116 [ -0.6% .. +0.8%]
wall_time 8.291 ± 0.174 8.307 ± 0.183 [ -1.1% .. +1.5%]
samples 21 25

Reviewed By: #lld-macho, thakis

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

show more ...

[lld/mac] Add a few TimeTraceScopes

Identical literal folding takes ~1.4% of the time, and was missing
from the trace.

Signature computation still needs ~2.2% of the time, so probably worth
explici

[lld/mac] Add a few TimeTraceScopes

Identical literal folding takes ~1.4% of the time, and was missing
from the trace.

Signature computation still needs ~2.2% of the time, so probably worth
explicitly marking its contribution to "Write output file" (9.1%)

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

show more ...

Rename parallelForEachN to just parallelFor

Patch created by running:

rg -l parallelForEachN | xargs sed -i '' -c 's/parallelForEachN/parallelFor/'

No behavior change.

Differential Revision: ht

Rename parallelForEachN to just parallelFor

Patch created by running:

rg -l parallelForEachN | xargs sed -i '' -c 's/parallelForEachN/parallelFor/'

No behavior change.

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

show more ...

[lld-macho][reland] Initial support for EH Frames

This reverts commit 942f4e3a7cc9a9f8b2654817cff12907d1276031.

The additional change required to avoid the assertion errors seen
previously is:

-

[lld-macho][reland] Initial support for EH Frames

This reverts commit 942f4e3a7cc9a9f8b2654817cff12907d1276031.

The additional change required to avoid the assertion errors seen
previously is:

--- a/lld/MachO/ICF.cpp
+++ b/lld/MachO/ICF.cpp
@@ -443,7 +443,9 @@ void macho::foldIdenticalSections() {
/*relocVA=*/0);
isec->data = copy;
}
- } else {
+ } else if (!isEhFrameSection(isec)) {
+ // EH frames are gathered as hashables from unwindEntry above; give a
+ // unique ID to everything else.
isec->icfEqClass[0] = ++icfUniqueID;
}
}

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

show more ...

Revert "[lld-macho] Initial support for EH Frames"

This reverts commit 826be330af9c0a8553a5b32718ecd2d97e10438e.

This was causing a test failure on build bots:
- https://lab.llvm.org/buildbot/#/b

Revert "[lld-macho] Initial support for EH Frames"

This reverts commit 826be330af9c0a8553a5b32718ecd2d97e10438e.

This was causing a test failure on build bots:
- https://lab.llvm.org/buildbot/#/builders/36/builds/21770
- https://lab.llvm.org/buildbot/#/builders/58/builds/23913

show more ...

[lld-macho] Initial support for EH Frames

== Background ==

`llvm-mc` generates unwind info in both compact unwind and DWARF
formats. LLD already handles the compact unwind format; this diff gets
us

[lld-macho] Initial support for EH Frames

== Background ==

`llvm-mc` generates unwind info in both compact unwind and DWARF
formats. LLD already handles the compact unwind format; this diff gets
us close to handling the DWARF format properly.

== Caveats ==

It's not quite done yet, but I figure it's worth getting this reviewed
and landed first as it's shaping up to be a fairly large code change.

**Known limitations of the current code:**

* Only works for x86_64, for which `llvm-mc` emits "abs-ified"
relocations as described in https://github.com/llvm/llvm-project/commit/618def651b59bd42c05bbd91d825af2fb2145683.
`llvm-mc` emits regular relocations for ARM EH frames, which we do not
yet handle correctly.

Since the feature is not ready for real use yet, I've gated it behind a
flag that only gets toggled on during test suite runs. With most of the
new code disabled, we see just a hint of perf regression, so I don't
think it'd be remiss to land this as-is:

base diff difference (95% CI)
sys_time 1.926 ± 0.168 1.979 ± 0.117 [ -1.2% .. +6.6%]
user_time 3.590 ± 0.033 3.606 ± 0.028 [ +0.0% .. +0.9%]
wall_time 7.104 ± 0.184 7.179 ± 0.151 [ -0.2% .. +2.3%]
samples 30 31

== Design ==

Like compact unwind entries, EH frames are also represented as regular
ConcatInputSections that get pointed to via `Defined::unwindEntry`. This
allows them to be handled generically by e.g. the MarkLive and ICF
code. (But note that unlike compact unwind subsections, EH frame
subsections do end up in the final binary.)

In order to make EH frames "look like" a regular ConcatInputSection,
some processing is required. First, we need to split the `__eh_frame`
section along EH frame boundaries rather than along symbol boundaries.
We do this by decoding the length field of each EH frame. Second, the
abs-ified relocations need to be turned into regular Relocs.

== Next Steps ==

In order to support EH frames on ARM targets, we will either have to
teach LLD how to handle EH frames with explicit relocs, or we can try to
make `llvm-mc` emit abs-ified relocs for ARM as well. I'm hoping to do
the latter as I think it will make the LLD implementation both simpler
and faster to execute.

== Misc ==

The `obj-file-with-stabs.s` test had to be updated as the previous
version would trip assertion errors in the code. It appears that in our
attempt to produce a minimal YAML test input, we created a file with
invalid EH frame data. I've fixed this by re-generating the YAML and not
doing any hand-pruning of it.

Reviewed By: #lld-macho, Roger

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

show more ...

[lld] Implement safe icf for MachO

This change implements --icf=safe for MachO based on addrsig section that is implemented in D123751.

Reviewed By: int3, #lld-macho

Differential Revision: https:/

[lld] Implement safe icf for MachO

This change implements --icf=safe for MachO based on addrsig section that is implemented in D123751.

Reviewed By: int3, #lld-macho

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

show more ...

[lld-macho] Fix ICF crash when comparing symbol relocs

Previously, when encountering a symbol reloc located in a literal section, we
would look up the contents of the literal at the `symbol value +

[lld-macho] Fix ICF crash when comparing symbol relocs

Previously, when encountering a symbol reloc located in a literal section, we
would look up the contents of the literal at the `symbol value + addend` offset
within the literal section. However, it seems that this offset is not guaranteed
to be valid. Instead, we should use just the symbol value to retrieve the
literal's contents, and compare the addend values separately. ld64 seems to do
this.

Reviewed By: #lld-macho, thevinster

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

show more ...

[lld-macho] Don't allocate memory in parallelForEach

... since BumpPtrAllocator isn't thread-safe.

Reviewed By: #lld-macho, Roger

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

[lld-macho] Deduplicate the `__objc_classrefs` section contents

ld64 breaks down `__objc_classrefs` on a per-word level and deduplicates
them. This greatly reduces the number of bind entries emitted

[lld-macho] Deduplicate the `__objc_classrefs` section contents

ld64 breaks down `__objc_classrefs` on a per-word level and deduplicates
them. This greatly reduces the number of bind entries emitted (and
therefore the amount of work `dyld` has to do at runtime). For
chromium_framework, this change to LLD cuts the number of (non-lazy)
binds from 912 to 190, getting us to parity with ld64 in this aspect.

Reviewed By: #lld-macho, thakis

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

show more ...

[lld-macho] Deduplicate CFStrings during ICF

`__cfstring` has embedded addends that foil ICF's hashing / equality
checks. (We can ignore embedded addends when doing ICF because the same
information

[lld-macho] Deduplicate CFStrings during ICF

`__cfstring` has embedded addends that foil ICF's hashing / equality
checks. (We can ignore embedded addends when doing ICF because the same
information gets recorded in our Reloc structs.) Therefore, in order to
properly dedup CFStrings, we create a mutable copy of the CFString and
zero out the embedded addends before performing any hashing / equality
checks.

(We did in fact have a partial implementation of CFString deduplication
already. However, it only worked when the cstrings they point to are at
identical offsets in their object files.)

I anticipate this approach can be extended to other similar
statically-allocated struct sections in the future.

In addition, we previously treated all references with differing addends
as unequal. This is not true when the references are to literals:
different addends may point to the same literal in the output binary. In
particular, `__cfstring` has such references to `__cstring`. I've
adjusted ICF's `equalsConstant` logic accordingly, and I've added a few
more tests to make sure the addend-comparison code path is adequately
covered.

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

Reviewed By: #lld-macho, Roger

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

show more ...

Re-land [lld-macho][nfc] Don't use `stubsHelperIndex` in ICF hash

Previous attempt was commit 112135e77444e8c8106efa77416af09f4b9a5012 and
reverted in d86d431814c836ec5579fc0b981e86c7fb81f2f2.

Revert "[lld-macho][nfc] Don't use `stubsHelperIndex` in ICF hash"

This reverts commit 112135e77444e8c8106efa77416af09f4b9a5012.
Breaks lld/test/MachO/{icf.s,cfstring-dedup.s,invalid/cfstring.s}

[lld-macho][nfc] Reduce size of icfEqClass hash

... from a `uint64_t` to a `uint32_t`. (LLD-ELF uses a `uint32_t` too.)

About a 1.7% reduction in peak RSS when linking chromium_framework on my
3.2

[lld-macho][nfc] Reduce size of icfEqClass hash

... from a `uint64_t` to a `uint32_t`. (LLD-ELF uses a `uint32_t` too.)

About a 1.7% reduction in peak RSS when linking chromium_framework on my
3.2 GHz 16-Core Intel Xeon W Mac Pro, and no stat sig change in wall
time.

</Users/jezng/test2.sh ["before"]> </Users/jezng/test2.sh ["after"]> difference (95% CI)
RSS 1003036672.000 ± 9891065.259 985539505.231 ± 10272748.749 [ -2.3% .. -1.2%]
samples 27 26

base diff difference (95% CI)
sys_time 1.277 ± 0.023 1.277 ± 0.024 [ -0.9% .. +0.9%]
user_time 6.682 ± 0.046 6.598 ± 0.043 [ -1.6% .. -0.9%]
wall_time 5.904 ± 0.062 5.895 ± 0.063 [ -0.7% .. +0.4%]
samples 46 28

No appreciable change (~0.01%) in number of `equals` comparisons either:

Before:

ld64.lld: ICF needed 8 iterations
ld64.lld: equalsConstant() called 701643 times
ld64.lld: equalsVariable() called 3438526 times

After:

ld64.lld: ICF needed 8 iterations
ld64.lld: equalsConstant() called 701729 times
ld64.lld: equalsVariable() called 3438526 times

Reviewed By: #lld-macho, MaskRay, thakis

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

show more ...

[lld-macho][nfc] Don't use `stubsHelperIndex` in ICF hash

The existing hashing of stubsHelperIndex has mostly been a no-op* for
some time now (ever since we made ICF run before dylib symbols get the

[lld-macho][nfc] Don't use `stubsHelperIndex` in ICF hash

The existing hashing of stubsHelperIndex has mostly been a no-op* for
some time now (ever since we made ICF run before dylib symbols get their
stubs indices assigned). I guess we could consider hashing the name +
filename of the DylibSymbol instead, but I'm not sure the overhead's
worth it... moreover, LLD/ELF only hashes their Defined symbols as well.

*: Technically it does change the hash value since stubsHelperIndex is
initialized to `UINT32_MAX` by default. But since all stubsHelperIndex
values are the same at when ICF runs, they don't add any useful
information to the hash.

show more ...

[lld-macho][nfc] Rename isec -> referentIsec to avoid shadowing

I found the shadowing a bit confusing

[lld-macho][nfc] Track # of ICF calls to `equals*` methods

This is debug code that is disabled by default. It'll provide a easy way
to figure out the impact (if any) of tweaking ICF's hashing algori

[lld-macho][nfc] Track # of ICF calls to `equals*` methods

This is debug code that is disabled by default. It'll provide a easy way
to figure out the impact (if any) of tweaking ICF's hashing algorithm
(since a poor quality hash will result in many more `equals*` calls).

Reviewed By: #lld-macho, oontvoo

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

show more ...

[lld-macho][nfc] Use llvm::function_ref instead of std::function

[lld-macho][nfc] Remove file statics from ICF.cpp

This gets us closer to the [LLD-as-a-library goal][1].

[1]: https://lists.llvm.org/pipermail/llvm-dev/2021-June/151184.html

Reviewed By: #lld-mach

[lld-macho][nfc] Remove file statics from ICF.cpp

This gets us closer to the [LLD-as-a-library goal][1].

[1]: https://lists.llvm.org/pipermail/llvm-dev/2021-June/151184.html

Reviewed By: #lld-macho, thakis

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

show more ...

[lld-macho][nfc] Move ICF-specific logic into ICF.cpp

This mirrors the code organization in `lld/ELF`.

Reviewed By: #lld-macho, thakis

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

[lld-macho] Don't include CommandFlags.h in CommonLinkerContext.h

Main motivation: including `llvm/CodeGen/CommandFlags.h` in
`CommonLinkerContext.h` means that the declaration of `llvm::Reloc` is
v

[lld-macho] Don't include CommandFlags.h in CommonLinkerContext.h

Main motivation: including `llvm/CodeGen/CommandFlags.h` in
`CommonLinkerContext.h` means that the declaration of `llvm::Reloc` is
visible in any file that includes `CommonLinkerContext.h`. Since our
cpp files have both `using namespace llvm` and `using namespace
lld::macho`, this results in conflicts with `lld::macho::Reloc`.

I suppose we could put `llvm::Reloc` into a nested namespace, but in general,
I think we should avoid transitively including too many header files in
a very widely used header like `CommonLinkerContext.h`.

RegisterCodeGenFlags' ctor initializes a bunch of function-`static`
structures and does nothing else, so it should be fine to "initialize"
it as a temporary stack variable rather than as a file static.

Reviewed By: aganea

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

show more ...

[lld/mac] Crash even less on undefined symbols with --icf=all

Follow-up to https://reviews.llvm.org/D112643. Even after that change, we were
still asserting if two separate functions that are eligib

[lld/mac] Crash even less on undefined symbols with --icf=all

Follow-up to https://reviews.llvm.org/D112643. Even after that change, we were
still asserting if two separate functions that are eligible for ICF (same size,
same data, same number of relocs, same reloc types, ...) referred to
Undefineds. This fixes that oversight.

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

show more ...

[lld-macho][nfc] Factor-out NFC changes from main __eh_frame diff

In order to keep signal:noise high for the `__eh_frame` diff, I have teased-out the NFC changes and put them here.

Differential Rev

[lld-macho][nfc] Factor-out NFC changes from main __eh_frame diff

In order to keep signal:noise high for the `__eh_frame` diff, I have teased-out the NFC changes and put them here.

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

show more ...