[lld] [lld] Elide __swift_FORCE_LOAD_$ dyld fixups in __DATA, __const (PR #214584)

Zhaoxuan Jiang via llvm-commits llvm-commits at lists.llvm.org
Thu Aug 13 00:24:42 PDT 2026


nocchijiang wrote:

> Do you mean: is the intention that these could coalesce with the autolink sections from other modules? How would you propose to make that work, by constructing the names based on the autolink fixups instead of the originating module?

Yes, coalescing across modules is what I meant. The anchors are already `weak_odr` and the `_$_<module>` suffix is the only thing preventing it. A name derived from the referenced symbol alone (a fixed `_ref` suffix) should suffice. But that's just my read of the Swift compiler code, and I'm not sure it's 100% correct - I couldn't find any code comment or commit history clarifying why appending the module name is necessary.

> FWIW this is largely based on a similar optimisation in ld64:
https://github.com/keith/ld64/blob/37d025c536163da612874999d0ea94a4e4e475e7/src/ld/passes/dylibs.cpp#L385-L389

Thanks for the pointer. I hadn't realized this mirrors ld64's behavior. Could we reference the ld64 code with a permalink in the commit message or a code comment, so later readers know the precedent? One difference stands out though: ld64 only nops the fixup and deliberately keeps the atoms and symbols "to ensure correct libraries are linked in". Since this PR goes further and removes the sections and symbols entirely, do you know what broke when ld64 tried stripping? I'd like to confirm the same hazard doesn't apply here (or is covered by the external-symbol guard) before we take the stronger approach.

https://github.com/llvm/llvm-project/pull/214584


More information about the llvm-commits mailing list