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

Joseph Huber via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jul 11 15:16:06 PDT 2023


jhuber6 added a comment.

In D154364#4491451 <https://reviews.llvm.org/D154364#4491451>, @efriedma wrote:

>> If we can maintain a map from some compiler builtin intrinsics to possible libcall functions that codegen can emit from them, it is possible that those functions can just be emitted as Undef in the LTO object symbol table
>
> The idea here is that we do the computation at compile-time, instead of making the linker do it? I suspect we end up with a few intrinsics where we can compute the mapping to libcalls somewhat precisely, alongside a long list of libcalls where the the result is unpredictable because it depends on codegen optimizations. So almost every object file would contain a long list of target-specific libcalls; I'm not sure that's the right tradeoff.

The LTO pass has access to the target machine when we run the backend. I'd presume that we could just let the target machine optionally export a list of libcalls it expects to be able to emit safely. It might be messy plumbing that information into the existing LTO handling however. I remember hearing @jdoerfert mentioning there's some similar set somewhere.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D154364



More information about the llvm-commits mailing list