[PATCH] D154364: [LTO] Allow library calls to be internalized in freestanding mode

[Daniel Thornburgh via Phabricator via llvm-commits]

mysterymath added a comment.

I've spent a surprising amount of time staring at this libcall list (originally in the context of https://discourse.llvm.org/t/lto-deplibs-and-libcalls-oh-my/64510). It's struck me as a bit of a hack; targets are free to change the names of libcalls in TLI or to include additional target-specific ones, and neither would end up in this list. LTO also depends on the accuracy of this list for correctness, since the symbol table of the link must be finalized before LTO codegen begins.

> If RuntimeLibcalls.def contains symbols that you don't actually need in specific scenarios, we need a mechanism to narrow the list somehow. Maybe we can add a target hook to get a target-specific list of relevant symbols.

I went a little ways down this route in https://reviews.llvm.org/D127885 to resolve https://github.com/llvm/llvm-project/issues/56070; maintaining per-target lists like this in the linker is a pretty rough maintenance burden.

It seems like it might be advantageous to provide a more direct way for the linker to query the code generator for this list via the LTO API; the code generator should be able to produce an accurate list from the configuration its provided by LLD.
Otherwise, we're left with the status quo, where the linker has to maintain in parallel a conservative description of the eventual behavior of the code generator. Any way in which that description is wrong is a way in which you can't use LTO.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D154364/new/

https://reviews.llvm.org/D154364