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

[Duncan P. N. Exon Smith]

On Mar 10, 2014, at 7:48 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:

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

[...]

> The system linker, yes. LLVM knows it is not seeing the full picture
> with regards to external ones.

I mistakenly assumed the LLVM perspective applied also to the system
linker (!).

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

That’s valuable work.  However, for this use case, there doesn’t seem
to be any benefit in relying on @llvm.compiler.used.  If I’d properly
understood how linkers work, I wouldn’t have complicated the flow in
the first place (i.e., I think r194514 should have just blocked
-internalize from giving these functions local linkage).

I’m also not sure what Module::getOrInsertFunction() *should* do when
it finds a function with local linkage in @llvm.compiler.used.  I
think its current behaviour is correct most of the time (moving
functions with local linkage seems correct in the usual case), and as
you point out below, checking for membership in @llvm.compiler.used
is not cheap.

> 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