[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