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

Krzysztof Parzyszek kparzysz at codeaurora.org
Mon Mar 10 12:30:43 PDT 2014


On 3/10/2014 11:49 AM, Duncan P. N. Exon Smith wrote:
>
> The general idea is: unless the linker has told us to preserve a symbol,
> internalize it, exposing it to other optimizations (like -globalopt).
> However, for library functions, this breaks down because later passes
> insert calls (e.g., -instcombine converts printf => puts, and
> -codegenprepare converts llvm.memcpy => memcpy).  So, add them to
> @llvm.compiler.used to protect them temporarily.

I see. Thanks for the explanation.


How about this: resolve symbols during LTO and detect which ones are 
used in the program, and which are not?  It would probably require a lot 
more work in the LTO framework, but it has the benefit that we no longer 
need any "preserve" list merely to allow it to link, or 
"internalization".  The only exception would be export lists for shared 
objects, but it would be a lot easier for the user to provide that, than 
to list all the functions referenced from other objects/libraries.

To help with user-provided library functions we could develop a way for 
the user to specify "resolution preference", i.e. if "printf" is not 
explicitly defined, pick it up from /usr/lib/libc.a, otherwise ignore 
the definition from libc.a.
This would only work for linking non-shared objects though.  If the user 
wants to get the rest of the functions from libc, the replaced ones 
would need to be internally renamed to avoid conflicts with those in 
libc (the system linker could otherwise complain).


Has anything like this been considered?



-Krzysztof

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation



More information about the llvm-dev mailing list