[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