[LLVMdev] [RFC] Linkage of user-supplied library functions in LTO
Duncan P. N. Exon Smith
dexonsmith at apple.com
Sat Mar 8 08:59:44 PST 2014
+nick and rafael, who seem to a lot about linkage.
I made the following claim on llmv-commits [1]:
On 2014 Mar 3, at 15:01, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
> Giving these functions internal linkage allows them to be dead-stripped.
Is that even correct?
This is the assumption I’ve been working under, but I’m not sure where I
got it from. It seems like the linker is free to dead-strip symbols
whether they’re internal or external.
The current state of user-supplied library functions in LTO is that we
internalize library functions, add them to llvm.compiler.used so that
optimizations don’t modify them, and then optimizations incorrectly
modify them. LLVM *really* doesn't expect library functions to have
local linkage.
And I’m not sure internal linkage is the right model anyway.
I see two paths forward:
1. Add a new linkage type called “linker_internal”, which LLVM treats as
a type of non-local linkage, but gets emitted as internal. This
might be worth it if linkers don’t dead strip external symbols.
2. If linkers *do* dead strip external symbols, then we should not
internalize user-supplied library functions in -internalize.
Do linkers dead strip symbols with external linkage? Any other reason to
prefer one path over the other? Is there another way?
Duncan
[1]: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140303/207033.html
More information about the llvm-dev
mailing list