[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

eddyz87 wrote: > > @eddyz87 , > > just create a new PR with the changes and make the cross references between > > this PR and the new one to let people easy find the original PR when > > necessary. > > Yup, this is the typical process (GitHub doesn't let you reopen a merged PR). Understood, t

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

AaronBallman wrote: > @eddyz87 , > > just create a new PR with the changes and make the cross references between > this PR and the new one to let people easy find the original PR when > necessary. Yup, this is the typical process (GitHub doesn't let you reopen a merged PR). https://github.co

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

vvereschaka wrote: @eddyz87 , just create a new PR with the changes and make the cross references between this PR and the new one to let people easy find the original PR when necessary. https://github.com/llvm/llvm-project/pull/101228 ___ cfe-commits

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

eddyz87 wrote: Hi @vvereschaka , Yes, I receive email notifications, the commit was reverted an hour ago. While at it, could you please help me understand current process, should I open a new pull request once I figure out the fix? https://github.com/llvm/llvm-project/pull/101228 _

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

vvereschaka wrote: Hi @eddyz87 , there are few failed `fastcall` tests on `[llvm-clang-x86_64-expensive-checks-ubuntu](https://lab.llvm.org/buildbot/#/builders/187) also https://lab.llvm.org/buildbot/#/builders/187/builds/509 * LLVM::bpf-fastcall-regmask-1.ll * LLVM::bpf-fastcall-1.ll * LLVM

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

llvm-ci wrote: LLVM Buildbot has detected a new failure on builder `llvm-clang-x86_64-expensive-checks-debian` running on `gribozavr4` while building `clang,llvm` at step 6 "test-build-unified-tree-check-all". Full details are available at: https://lab.llvm.org/buildbot/#/builders/16/builds/3

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

eddyz87 wrote: @AaronBallman, could you please help me with the procedural question: I reverted the commit and current pull request is now closed, what should I do when I'll figure out the fix? It looks like there is no option to re-open pull request, hence it looks like I will have to open a n

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

eddyz87 wrote: There was a failure for expansive checks: https://lab.llvm.org/buildbot/#/builders/187/builds/509 I reverted the commit, will investigate. https://github.com/llvm/llvm-project/pull/101228 ___ cfe-commits mailing list cfe-commits@lists.l

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

https://github.com/eddyz87 closed https://github.com/llvm/llvm-project/pull/101228 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

eddyz87 wrote: > Then I think we're good to land! @eddyz87 do you need someone to land on your > behalf? @AaronBallman, I have commit rights, will merge this change shortly, thank you! https://github.com/llvm/llvm-project/pull/101228 ___ cfe-commits

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

AaronBallman wrote: > @AaronBallman the llvm side of change looks good to me! Then I think we're good to land! @eddyz87 do you need someone to land on your behalf? https://github.com/llvm/llvm-project/pull/101228 ___ cfe-commits mailing list cfe-comm

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

yonghong-song wrote: @AaronBallman the llvm side of change looks good to me! https://github.com/llvm/llvm-project/pull/101228 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

eddyz87 wrote: > Clang bits LGTM; accepting but please wait to land until someone accepts the > LLVM changes as well. @AaronBallman , thank you for the review! On the LLVM side the changes are only for BPF backend and these were already approved by @yonghong-song, or do you have someone else i

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

https://github.com/AaronBallman approved this pull request. Clang bits LGTM; accepting but please wait to land until someone accepts the LLVM changes as well. https://github.com/llvm/llvm-project/pull/101228 ___ cfe-commits mailing list cfe-commits@li

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

@@ -2189,6 +2189,14 @@ def BTFTypeTag : TypeAttr { let LangOpts = [COnly]; } +def BPFFastCall : InheritableAttr, + TargetSpecificAttr { + let Spellings = [Clang<"bpf_fastcall">]; + let Subjects = SubjectList<[FunctionLike]>; + let Documentation = [BPFFast

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

https://github.com/eddyz87 updated https://github.com/llvm/llvm-project/pull/101228 >From 6a3b5c79d148863f39b84ce3da4e4794829c1c56 Mon Sep 17 00:00:00 2001 From: Eduard Zingerman Date: Wed, 8 May 2024 15:29:47 -0700 Subject: [PATCH 1/6] [BPF] introduce __attribute__((bpf_fastcall)) This commit

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

@@ -2189,6 +2189,14 @@ def BTFTypeTag : TypeAttr { let LangOpts = [COnly]; } +def BPFFastCall : InheritableAttr, + TargetSpecificAttr { + let Spellings = [Clang<"bpf_fastcall">]; + let Subjects = SubjectList<[FunctionLike]>; + let Documentation = [BPFFast

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

@@ -2189,6 +2189,14 @@ def BTFTypeTag : TypeAttr { let LangOpts = [COnly]; } +def BPFFastCall : InheritableAttr, + TargetSpecificAttr { + let Spellings = [Clang<"bpf_fastcall">]; + let Subjects = SubjectList<[FunctionLike]>; + let Documentation = [BPFFast

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

https://github.com/eddyz87 updated https://github.com/llvm/llvm-project/pull/101228 >From 6a3b5c79d148863f39b84ce3da4e4794829c1c56 Mon Sep 17 00:00:00 2001 From: Eduard Zingerman Date: Wed, 8 May 2024 15:29:47 -0700 Subject: [PATCH 1/5] [BPF] introduce __attribute__((bpf_fastcall)) This commit

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

@@ -0,0 +1,7 @@ +// REQUIRES: bpf-registered-target +// RUN: %clang_cc1 %s -triple bpf -verify + +__attribute__((bpf_fastcall)) int var; // expected-warning {{'bpf_fastcall' attribute only applies to functions and function pointers}} + +__attribute__((bpf_fastcall)) void func();

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

@@ -2189,6 +2189,14 @@ def BTFTypeTag : TypeAttr { let LangOpts = [COnly]; } +def BPFFastCall : InheritableAttr, + TargetSpecificAttr { + let Spellings = [GCC<"bpf_fastcall">]; eddyz87 wrote: GCC will have to catch-up, but the would also h

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

@@ -2189,6 +2189,14 @@ def BTFTypeTag : TypeAttr { let LangOpts = [COnly]; } +def BPFFastCall : InheritableAttr, + TargetSpecificAttr { + let Spellings = [GCC<"bpf_fastcall">]; + let Subjects = SubjectList<[FunctionLike]>; AaronBallman wro

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

@@ -2189,6 +2189,14 @@ def BTFTypeTag : TypeAttr { let LangOpts = [COnly]; } +def BPFFastCall : InheritableAttr, + TargetSpecificAttr { + let Spellings = [GCC<"bpf_fastcall">]; + let Subjects = SubjectList<[FunctionLike]>; eddyz87 wrote:

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

@@ -2189,6 +2189,14 @@ def BTFTypeTag : TypeAttr { let LangOpts = [COnly]; } +def BPFFastCall : InheritableAttr, + TargetSpecificAttr { + let Spellings = [GCC<"bpf_fastcall">]; AaronBallman wrote: Does GCC support this attribute with this

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

@@ -2189,6 +2189,14 @@ def BTFTypeTag : TypeAttr { let LangOpts = [COnly]; } +def BPFFastCall : InheritableAttr, + TargetSpecificAttr { + let Spellings = [GCC<"bpf_fastcall">]; + let Subjects = SubjectList<[FunctionLike]>; AaronBallman wro

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

@@ -0,0 +1,7 @@ +// REQUIRES: bpf-registered-target +// RUN: %clang_cc1 %s -triple bpf -verify + +__attribute__((bpf_fastcall)) int var; // expected-warning {{'bpf_fastcall' attribute only applies to functions and function pointers}} + +__attribute__((bpf_fastcall)) void func();

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

AaronBallman wrote: Thank you (all) for the explanations, that was helpful -- it addressed my concerns with the design. https://github.com/llvm/llvm-project/pull/101228 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

eddyz87 wrote: @AaronBallman, @efriedma-quic, could you please comment? We are eager to use this feature on the BPF side (e.g. [here](https://lore.kernel.org/bpf/caadnvqjdki9gcxdaagjwb+hrkt2enzyxm8k3238xxpthkhu...@mail.gmail.com/) and landing it to the `main` would simplify the cooperation. ht

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

yonghong-song wrote: @AaronBallman Just want to clarify about linking. For bpf ecosystem, we do not do linking with llvm lld. We do linking with bpftool (see https://www.mankier.com/8/bpftool-gen) as there are special requirements to *glue* bpf programs together. In bpf_fastcall use case, the

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

eddyz87 wrote: @AaronBallman, > But a mismatch can still potentially result in a miscompilation, right? e.g., > you have a function in a header file with the `bfp_fastcall` attribute on it. > The definition of the function is compiled into a library with Clang 16 and > ignores the unknown att

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

AaronBallman wrote: > If attribute is dropped, then yes. E.g. if function is called through `ptr2` > from the example above, the register allocator would assume that all caller > saved registers are clobbered. However, the generated code is still correct, > nothing will break or behave unexpec

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

eddyz87 wrote: @AaronBallman, > > ```c > > void (*ptr1)(void) __bpf_fastcall; > > void (*ptr2)(void); > > void foo(void) { > > ptr2 = ptr1; // is this an error? > > } > > ``` > ... > Doesn't that kind of defeat the purpose of the calling convention? (A > function designato

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

AaronBallman wrote: > > Is there some reason this is an attribute, and not a calling convention, at > > the IR level? > > Thought about it and decided against that, but I agree that this is an > option, my reasoning below. From the semantic point of view the difference > between current attri

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

eddyz87 wrote: @AaronBallman , @efriedma-quic , could you please check my last comment [here](https://github.com/llvm/llvm-project/pull/101228#issuecomment-2263848414)? https://github.com/llvm/llvm-project/pull/101228 ___ cfe-commits mailing list cfe-

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

@@ -596,6 +600,90 @@ bool BPFMIPreEmitPeephole::adjustBranch() { return Changed; } +static const unsigned CallerSavedRegs[] = {BPF::R0, BPF::R1, BPF::R2, + BPF::R3, BPF::R4, BPF::R5}; + +struct BPFFastCall { + MachineInstr *MI; + u

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

https://github.com/eddyz87 updated https://github.com/llvm/llvm-project/pull/101228 >From 6a3b5c79d148863f39b84ce3da4e4794829c1c56 Mon Sep 17 00:00:00 2001 From: Eduard Zingerman Date: Wed, 8 May 2024 15:29:47 -0700 Subject: [PATCH 1/3] [BPF] introduce __attribute__((bpf_fastcall)) This commit

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

@@ -596,6 +600,90 @@ bool BPFMIPreEmitPeephole::adjustBranch() { return Changed; } +static const unsigned CallerSavedRegs[] = {BPF::R0, BPF::R1, BPF::R2, + BPF::R3, BPF::R4, BPF::R5}; + +struct BPFFastCall { + MachineInstr *MI; + u

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

@@ -596,6 +600,90 @@ bool BPFMIPreEmitPeephole::adjustBranch() { return Changed; } +static const unsigned CallerSavedRegs[] = {BPF::R0, BPF::R1, BPF::R2, + BPF::R3, BPF::R4, BPF::R5}; + +struct BPFFastCall { + MachineInstr *MI; + u

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

@@ -596,6 +600,90 @@ bool BPFMIPreEmitPeephole::adjustBranch() { return Changed; } +static const unsigned CallerSavedRegs[] = {BPF::R0, BPF::R1, BPF::R2, + BPF::R3, BPF::R4, BPF::R5}; + +struct BPFFastCall { + MachineInstr *MI; + u

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

@@ -0,0 +1,24 @@ +// REQUIRES: bpf-registered-target +// RUN: %clang_cc1 -triple bpf -emit-llvm -disable-llvm-passes %s -o - | FileCheck %s + +#define __bpf_fastcall __attribute__((bpf_fastcall)) + +void test(void) __bpf_fastcall; +void (*ptr)(void) __bpf_fastcall; + +void foo(vo

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

@@ -0,0 +1,24 @@ +// REQUIRES: bpf-registered-target +// RUN: %clang_cc1 -triple bpf -emit-llvm -disable-llvm-passes %s -o - | FileCheck %s + +#define __bpf_fastcall __attribute__((bpf_fastcall)) + +void test(void) __bpf_fastcall; +void (*ptr)(void) __bpf_fastcall; + +void foo(vo

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

@@ -0,0 +1,24 @@ +// REQUIRES: bpf-registered-target +// RUN: %clang_cc1 -triple bpf -emit-llvm -disable-llvm-passes %s -o - | FileCheck %s + +#define __bpf_fastcall __attribute__((bpf_fastcall)) + +void test(void) __bpf_fastcall; +void (*ptr)(void) __bpf_fastcall; + +void foo(vo

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

@@ -596,6 +600,90 @@ bool BPFMIPreEmitPeephole::adjustBranch() { return Changed; } +static const unsigned CallerSavedRegs[] = {BPF::R0, BPF::R1, BPF::R2, + BPF::R3, BPF::R4, BPF::R5}; + +struct BPFFastCall { + MachineInstr *MI; + u

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

@@ -596,6 +600,90 @@ bool BPFMIPreEmitPeephole::adjustBranch() { return Changed; } +static const unsigned CallerSavedRegs[] = {BPF::R0, BPF::R1, BPF::R2, + BPF::R3, BPF::R4, BPF::R5}; + +struct BPFFastCall { + MachineInstr *MI; + u

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

@@ -596,6 +600,90 @@ bool BPFMIPreEmitPeephole::adjustBranch() { return Changed; } +static const unsigned CallerSavedRegs[] = {BPF::R0, BPF::R1, BPF::R2, + BPF::R3, BPF::R4, BPF::R5}; + +struct BPFFastCall { + MachineInstr *MI; + u

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

@@ -0,0 +1,24 @@ +// REQUIRES: bpf-registered-target +// RUN: %clang_cc1 -triple bpf -emit-llvm -disable-llvm-passes %s -o - | FileCheck %s + +#define __bpf_fastcall __attribute__((bpf_fastcall)) + +void test(void) __bpf_fastcall; +void (*ptr)(void) __bpf_fastcall; + +void foo(vo

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

@@ -0,0 +1,24 @@ +// REQUIRES: bpf-registered-target +// RUN: %clang_cc1 -triple bpf -emit-llvm -disable-llvm-passes %s -o - | FileCheck %s + +#define __bpf_fastcall __attribute__((bpf_fastcall)) + +void test(void) __bpf_fastcall; +void (*ptr)(void) __bpf_fastcall; + +void foo(vo

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

https://github.com/yonghong-song approved this pull request. I also tried a few examples and it looks good to me. Only a few minor comments. https://github.com/llvm/llvm-project/pull/101228 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https:

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

@@ -0,0 +1,24 @@ +// REQUIRES: bpf-registered-target +// RUN: %clang_cc1 -triple bpf -emit-llvm -disable-llvm-passes %s -o - | FileCheck %s + +#define __bpf_fastcall __attribute__((bpf_fastcall)) + +void test(void) __bpf_fastcall; +void (*ptr)(void) __bpf_fastcall; + +void foo(vo

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

https://github.com/yonghong-song edited https://github.com/llvm/llvm-project/pull/101228 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

eddyz87 wrote: > Is there some reason this is an attribute, and not a calling convention, at > the IR level? Thought about it and decided against that, but I agree that this is an option, my reasoning below. >From the semantic point of view the difference between current attribute >implementa

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

AaronBallman wrote: > Is there some reason this is an attribute, and not a calling convention, at > the IR level? And why would it not be named `__attribute__((fastcall))` when targeting BPF? (e.g., do we need a new calling convention at all?) https://github.com/llvm/llvm-project/pull/101228

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

efriedma-quic wrote: Is there some reason this is an attribute, and not a calling convention, at the IR level? https://github.com/llvm/llvm-project/pull/101228 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mail

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

llvmbot wrote: @llvm/pr-subscribers-clang-codegen Author: None (eddyz87) Changes This commit introduces attribute bpf_fastcall to declare BPF functions that do not clobber some of the caller saved registers (R0-R5). The idea is to generate the code complying with generic BPF ABI, but all

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

https://github.com/eddyz87 ready_for_review https://github.com/llvm/llvm-project/pull/101228 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

https://github.com/eddyz87 edited https://github.com/llvm/llvm-project/pull/101228 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

https://github.com/eddyz87 updated https://github.com/llvm/llvm-project/pull/101228 >From 6a3b5c79d148863f39b84ce3da4e4794829c1c56 Mon Sep 17 00:00:00 2001 From: Eduard Zingerman Date: Wed, 8 May 2024 15:29:47 -0700 Subject: [PATCH] [BPF] introduce __attribute__((bpf_fastcall)) This commit int

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

https://github.com/eddyz87 updated https://github.com/llvm/llvm-project/pull/101228 >From 1a123ec3f3dd5b9df0a4f7694c09fbbe121450bd Mon Sep 17 00:00:00 2001 From: Eduard Zingerman Date: Wed, 8 May 2024 15:29:47 -0700 Subject: [PATCH] [BPF] introduce __attribute__((bpf_fastcall)) This commit int

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

github-actions[bot] wrote: :warning: C/C++ code formatter, clang-format found issues in your code. :warning: You can test this locally with the following command: ``bash git-clang-format --diff 247251aee0d4314385a3fea86e31484d3d792ffb 02af8355ccdfb41199168a2b71c1b25a491a6310 --e

[clang] [llvm] [BPF] introduce `__attribute__((bpf_fastcall))` (PR #101228)

https://github.com/eddyz87 created https://github.com/llvm/llvm-project/pull/101228 This commit introduces attribute bpf_fastcall to declare BPF functions that do not clobber some of the caller saved registers (R0-R5). The idea is to generate the code complying with generic BPF ABI, but allow