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

Rafael Espíndola rafael.espindola at gmail.com
Mon Mar 10 11:11:31 PDT 2014


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

More or less. There is still a (very small) advantage of having
internal + llvm.compiler.used. In the case llvm does introduce an use
to it, the linker cannot GC it, but will not put it in the symbol
table of the resulting DSO.

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

I think it shouldn't be doing any special treatment. I mean, the
function is named getOrInsertFunction. It is surprising that it does
an insert when there is a function already :-) That functionality
should probably be moved to another, clearly named function.

Cheers,
Rafael




More information about the llvm-dev mailing list