[llvm] [BPF] Define empty set of BPF libcalls (PR #169537)

Tue Dec 2 08:56:09 PST 2025

LucasSte wrote:

> it does that if the libcall is not defined right?

As far as I can tell, each target defines which lib calls are available in [RuntimeLibcalls.td](https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/IR/RuntimeLibcalls.td). It is up to the LLVM target to decide whether to support a lib function or not.

But I'm curious about your message. Can you provide an example of llvm-ir where you don't hit that error?

> rustc does provide libcalls definitions

You have functions implemented in compiler-builtins, but the decision on whether to use them relies on LLVM code generation for each target. Libcalls are defined by each target in `RuntimeLibcalls.td` regardless of the front-end programming language.

> I mean sure in an ideal world, but that's not how it works today, and this is going to break things that use the bpf target and bring their own libcalls (eg aya).
> In aya we must make sure that the memops don't return the dest pointer (like many implementations do), because returning stack pointers is disallowed by the kernel verifier.

Thanks for pointing that out. This change shouldn't be breaking downstream users. LLVM will inline instructions that represent the function without any call instruction. If you've found llvm-ir generated by this patch that does not pass verification, can you show an example? I will include the fix in this PR, since that might be a code path that C programs may also need.

> In some other user space eBPF implementation, we have special memcpy/memset code.

That sounds like you need another ABI, right? If the user space implementation does not exactly replicate the kernel environment, then you have different properties. I believe this was the point made in https://github.com/llvm/llvm-project/pull/169537#issuecomment-3577682897 by one of the maintainers.

> sounds like we should expand _if_ the libcall isn't there?

Can you elaborate more on how that should look like in LLVM?

The first version of this PR proposed a set removing only the i128 related functions, but there was a recommendation against that version, since we would be hitting the error in codegen for all external calls. See: https://github.com/llvm/llvm-project/pull/169537#pullrequestreview-3506921274

https://github.com/llvm/llvm-project/pull/169537