[llvm] [BPF] Define empty set of BPF libcalls (PR #169537)
Matt Arsenault via llvm-commits
llvm-commits at lists.llvm.org
Sun Dec 7 12:25:28 PST 2025
arsenm wrote:
> But when compiling eBPF rustc forces LTO, all the code is merged in one module and the libcalls are not external.
The legalizer does not know if the function it is trying to call is external or defined in the module. The behavior is the same either way.
> If we disable libcalls entirely, I think every larger memcpy would result in an error, no?
> When we disable libcalls, then compiler-builtins' implementation won't be used,
BPF has no libcalls today. All cases that emit libcalls error, whether the function is defined or not, e.g. https://godbolt.org/z/dGon9fn64. So I don't understand how you see it's possible to link a custom function today, they will all compiler error
The current BPF memcpy handling looks incomplete. getCommonMaxStoresPerMemFunc should be set to the maximum to ensure the general expansion already triggers, or unconditionally use BPFISD::MEMCPY?
https://github.com/llvm/llvm-project/pull/169537
More information about the llvm-commits
mailing list