================
@@ -443,6 +450,14 @@ class LTO {
LLVM_ABI static SmallVector<const char *>
getRuntimeLibcallSymbols(const Triple &TT);
+ /// Static method that returns a list of library function symbols that can be
+ /// generated by LTO but might not be visible from bitcode symbol table.
+ /// Unlike the runtime libcalls, the linker can report to the code generator
+ /// which of these are actually available in the link, and the code generator
+ /// can then only reference that set of symbols.
+ LLVM_ABI static SmallVector<StringRef>
+ getLibFuncSymbols(const Triple &TT, llvm::StringSaver &Saver);
----------------
mysterymath wrote:
In this patch, the linker treats the two sets of symbols differently. Runtime
libcalls are not optional; the code generator doesn't generally have the
ability to, say, never emit a memcpy. So any such symbols must be summarily
extracted, regardless of whether they appear used. With libfuncs, the linker
can merely report which are implemented in bitcode and trust that the code
generator will not emit any new references to such symbols.
I do agree that one data structure should eventually be responsible for
representing this knowledge though, as it's essentially just a bit of
information per symbol on whether or not the code generator can promise not to
emit the symbol.
https://github.com/llvm/llvm-project/pull/164916
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
