[BPF] Allow libcalls behind a feature gate #168442

LucasSte · 2025-11-17T21:07:59Z

Problem

In Rust, checked math functions (like checked_mul, overflowing_mul, saturating_mul) are part of the primitive implementation of integers (see u64 for instance). The Rust compiler builds the Rust compiler-builtins crate as a step in the compilation processes, since it contains the math builtins to be lowered in the target.

For BPF, however, when using those functions in Rust we hit the following errors:

ERROR llvm: <unknown>:0:0: in function func i64 (i64, i64): A call to built-in function '__multi3' is not supported.

ERROR llvm: <unknown>:0:0: in function func i64 (i64, i64): only small returns supported

Those errors come from the following code:

pub fn func(a: u64, b: u64) -> u64 {
    a.saturating_mul(b)
}

Those functions invoke underneath the llvm instrinc { i64, i1 } @llvm.umul.with.overflow.i64(i64, i64) or its variants.

It is very useful to use safe math operations when writing BPF code in Rust, and I would like to add support for those in the target.

Changes

Create a target feature allow-builtin-calls to enable code generation for builtin functions.
Implement CanLowerReturn to fix the error only small returns supported.
Add code to correctly invoke lib functions.
Add a test case together with the corresponding C code.

github-actions · 2025-11-17T21:08:19Z

Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this page.

If this is not working for you, it is probably because you do not have write permissions for the repository. In which case you can instead tag reviewers by name in a comment by using @ followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a review by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate is once a week. Please remember that you are asking for valuable time from other developers.

If you have further questions, they may be answered by the LLVM GitHub User Guide.

You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums.

LucasSte · 2025-11-18T19:02:58Z

@yonghong-song gentle ping

vadorovsky

Great stuff!

Could you add the [BPF] tag and description to your commit message as well?

vadorovsky · 2025-11-18T09:32:00Z

llvm/lib/Target/BPF/BPFISelLowering.cpp

+      if (!AllowBuiltinCalls) {
+        fail(CLI.DL, DAG,
+             Twine("A call to built-in function '" + StringRef(E->getSymbol()) +
+                   "' is not supported."));
+      }


Nit: usually if statements with one-liners are written without braces in the BPF backend code:

Suggested change

if (!AllowBuiltinCalls) {

fail(CLI.DL, DAG,

Twine("A call to built-in function '" + StringRef(E->getSymbol()) +

"' is not supported."));

}

if (!AllowBuiltinCalls)

fail(CLI.DL, DAG,

Twine("A call to built-in function '" + StringRef(E->getSymbol()) +

"' is not supported."));

Since this is a simple change, I'll add it to the existing commit in this PR and force push it again with the correct title you asked for.

github-actions · 2025-11-18T20:13:59Z

🐧 Linux x64 Test Results

186429 tests passed
4864 tests skipped

yonghong-song

Please explain how bpf program handles builtin function like __multi3() in rust environment. Currently the builtin function like __multi3() won't work for libbpf and kernel as there is no actual function for __multi3() in final bpf program.

yonghong-song · 2025-11-19T19:09:01Z

llvm/lib/Target/BPF/BPFISelLowering.h

  EmitInstrWithCustomInserterLDimm64(MachineInstr &MI,
                                     MachineBasicBlock *BB) const;
+
+  /// Returns true if arguments should be sign-extended in lib calls.


Let us do

// Returns true if arguments should be sign-extended in lib calls.

similar to the comments in previous lines.

Did I miss anything or is your suggestion the same thing as what I wrote there already?

Ah, sorry, I didn't see you were using two slashes.

Fixed the comment in the squashed commit.

yonghong-song · 2025-11-19T19:10:12Z

llvm/test/CodeGen/BPF/builtin_calls.ll

+; CHECK: r5 s>>= 63
+; CHECK: r1 = r10
+; CHECK: r1 += -16
+; CHECK: call __multi3


Could you explain in the commit/description message how do you handle __multi3 function? This is clang built-in so you will implement this function in the bpf prog?

When we build the core library in Rust, which implements the primitive types and their math operations, we also build as a dependency Rust's compiler-builtin crate. This crate has the implementation of __multi3 (see https://github.com/rust-lang/compiler-builtins/blob/eba1a3f3d2824739f07fe434624b0d2fee917d89/compiler-builtins/src/int/mul.rs#L108-L110).

Once we build the target program and all the dependencies (core and compiler-builtins), we merge all LLVM modules and emit a final object.

Is this message clear for the commit?

I updated the commit message. Let me know if it is clear. I'm happy to re-write it.

yonghong-song · 2025-11-19T19:13:12Z

llvm/test/CodeGen/BPF/struct_ret2.ll

 ; RUN: not llc -mtriple=bpf < %s 2> %t1
 ; RUN: FileCheck %s < %t1
-; CHECK: only small returns
+; CHECK: aggregate returns are not supported


For struct_ret2.ll, the following is the error message:

$ llc -march=bpf test/CodeGen/BPF/struct_ret2.ll error: <unknown>:0:0: in function foo { i64, i32 } (i32, i32, i32): 0x3d86ac0: i64 = GlobalAddress<ptr @bar> 0 too many arguments error: <unknown>:0:0: in function foo { i64, i32 } (i32, i32, i32): aggregate returns are not supported

I suggest to have the first error message for CHECK, i.e., 'too many arguments" which is caused by CanLowerReturn().

Please also update struct_ret1.ll like below:

$ llc -march=bpf test/CodeGen/BPF/struct_ret1.ll error: <unknown>:0:0: in function bar { i64, i32 } (i32, i32, i32, i32, i32): stack arguments are not supported error: <unknown>:0:0: in function bar { i64, i32 } (i32, i32, i32, i32, i32): aggregate returns are not supported error: <unknown>:0:0: in function baz void (ptr): aggregate returns are not supported

Similarly, I would like the error message in CHECK should be the first error message.

Fixed both tests in the squashed commit.

When we build the core library in Rust, which implements the primitive types an their math operations, we also build as a dependency Rust's compiler-builtin[0] crate. This crate has the implementation of __multi3 [1]. Once we build the target program and all the dependencies (core and compiler-builtins), we merge all LLVM modules and emit a final object. [0] https://github.com/rust-lang/compiler-builtins [1] https://github.com/rust-lang/compiler-builtins/blob/eba1a3f3d2824739f07fe434624b0d2fee917d89/compiler-builtins/src/int/mul.rs#L108-L110

yonghong-song

Thanks, LGTM.

LucasSte changed the title ~~Allow libcalls in BPF (behind a feature gate)~~ [BPF] Allow libcalls behind a feature gate Nov 18, 2025

grod220 mentioned this pull request Nov 18, 2025

SIMD-0391: Stake Program Float to Fixed-Point solana-foundation/solana-improvement-documents#391

Open

yonghong-song requested review from eddyz87 and yonghong-song November 18, 2025 19:30

vadorovsky reviewed Nov 18, 2025

View reviewed changes

LucasSte force-pushed the bpf-libcalls branch from 4808ce5 to a1e74bf Compare November 19, 2025 14:23

yonghong-song reviewed Nov 19, 2025

View reviewed changes

LucasSte force-pushed the bpf-libcalls branch from a1e74bf to c9e6e0c Compare November 20, 2025 17:59

LucasSte requested a review from yonghong-song November 20, 2025 18:05

yonghong-song approved these changes Nov 21, 2025

View reviewed changes

[BPF] Allow libcalls behind a feature gate #168442

Are you sure you want to change the base?

[BPF] Allow libcalls behind a feature gate #168442

Uh oh!

Conversation

LucasSte commented Nov 17, 2025

Uh oh!

github-actions bot commented Nov 17, 2025

Uh oh!

LucasSte commented Nov 18, 2025

Uh oh!

vadorovsky left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions bot commented Nov 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🐧 Linux x64 Test Results

Uh oh!

yonghong-song left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yonghong-song left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

github-actions bot commented Nov 18, 2025 •

edited

Loading