[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