[LLVMdev] [RFC] Linkage of user-supplied library functions in LTO

Rafael Espíndola rafael.espindola at gmail.com
Mon Mar 10 07:48:16 PDT 2014


>> Giving these functions internal linkage allows them to be dead-stripped.
>
> Is that even correct?

By LLVM point of view, yes. It can drop linkonce and local (private* +
internal) globals.

> 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 system linker, yes. LLVM knows it is not seeing the full picture
with regards to external ones.

> 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.

Why not just fix the optimizations that are not handling
llvm.compiler.used correctly?

> 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?

So, linkers have a better view of what is and is not used. They pass
that information down to LLVM during link. The thing llvm has to be
careful about are symbols it can introduce calls to (like memcpy). For
those llvm.compiler.used should be fine.

Using llvm.compiler.used and llvm.used is pretty annoying, and should
probably be made into an easier to use attribute, but probably not
folded into linkage. It is pretty orthogonal to other linkage
properties. We can have a llvm.used that is weak_odr, external or
internal for example.

Cheers,
Rafael




More information about the llvm-dev mailing list