[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 · 2025-11-24T13:54:52Z

@yonghong-song Thanks for the approval.

Is there any other feedback I need to address to get this PR merged? I don't have permissions to merge it myself.

github-actions · 2025-11-24T17:03:10Z

@LucasSte Congratulations on having your first Pull Request (PR) merged into the LLVM Project!

Your changes will be combined with recent changes from other authors, then tested by our build bots. If there is a problem with a build, you may receive a report in an email or a comment on this PR.

Please check whether problems have been caused by your change specifically, as the builds can include changes from many authors. It is not uncommon for your change to be included in a build that fails due to someone else's changes, or infrastructure issues.

How to do this, and the rest of the post-merge process, is covered in detail here.

If your change does cause a problem, it may be reverted, or you can revert it yourself. This is a normal part of LLVM development. You can fix your changes and open a new PR to merge them again.

If you don't get any reports, no action is required from you. Your changes are working as expected, well done!

yonghong-song · 2025-11-24T17:03:30Z

Is there any other feedback I need to address to get this PR merged? I don't have permissions to merge it myself.

Looks like there are no other coments. Just merged.

arsenm · 2025-11-24T17:29:43Z

Create a target feature allow-builtin-calls to enable code generation for builtin functions.

This should not be a subtarget feature

arsenm

This is the wrong solution to the problem. BPF isn't correctly configuring its set of RuntimeLibcalls. If you removed the function from the default set, you should hit the software expansion without hitting the external call.

Whether or not the libcall is available should be treated as an ABI property, preferably directly implied by the triple without a function-level control like a subtarget feature

arsenm · 2025-11-24T17:30:33Z

llvm/lib/Target/BPF/BPFISelLowering.cpp

+  SmallVector<CCValAssign, 16> RVLocs;
+  CCState CCInfo(CallConv, IsVarArg, MF, RVLocs, Context);
+  return CCInfo.CheckReturn(Outs, getHasAlu32() ? RetCC_BPF32 : RetCC_BPF64);
+}


End of file whitespace error

arsenm · 2025-11-24T17:30:41Z

llvm/lib/Target/BPF/BPFISelLowering.cpp

+  return IsSigned || Ty->isIntegerTy(32);
+}
+
+bool BPFTargetLowering::CanLowerReturn(


This should be a separate change

arsenm · 2025-11-24T17:30:46Z

llvm/lib/Target/BPF/BPFISelLowering.cpp

@@ -1196,3 +1198,18 @@ bool BPFTargetLowering::isLegalAddressingMode(const DataLayout &DL,

  return true;
 }
+
+bool BPFTargetLowering::shouldSignExtendTypeInLibCall(Type *Ty,


This is a separate change

LucasSte · 2025-11-24T19:05:02Z

This is the wrong solution to the problem. BPF isn't correctly configuring its set of RuntimeLibcalls. If you removed the function from the default set, you should hit the software expansion without hitting the external call.

Are you suggesting that we create an entry in RuntimeLibcalls.td to specify which lib calls are not available in BPF?

Whether or not the libcall is available should be treated as an ABI property, preferably directly implied by the triple without a function-level control like a subtarget feature

When building a Rust program for BPF we do build the compiler-builtins crate, so ultimately we link everything together. Should we have a specific setting to identify we are building a program for Rust?

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

yonghong-song merged commit 23907a2 into llvm:main Nov 24, 2025
10 checks passed

arsenm reviewed Nov 24, 2025

View reviewed changes

[BPF] Allow libcalls behind a feature gate #168442

[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!

LucasSte commented Nov 24, 2025

Uh oh!

Uh oh!

github-actions bot commented Nov 24, 2025

Uh oh!

yonghong-song commented Nov 24, 2025

Uh oh!

arsenm commented Nov 24, 2025

Uh oh!

arsenm 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!

LucasSte commented Nov 24, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

github-actions bot commented Nov 18, 2025 •

edited

Loading