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

[Aaron Ballman via llvm-commits]

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 attribute implementation and calling convention would be whether the code below reports be an error:
> 
> ```c
>     void (*ptr1)(void) __bpf_fastcall;
>     void (*ptr2)(void);
>     void foo(void) {
>       ptr2 = ptr1; // is this an error?
>     }
> ```
> 
> From the Kernel point of view it really is not, as this "fast call" is an optimization hint, that could be safely ignored by BPF jit. Plus desire to keep clang front-end changes to the minimum. Also, the argument made for `preserve_caller_saved_registers` [here](https://reviews.llvm.org/D22045#494112) sort-of makes sense for `bpf_fastcall` as well.

Doesn't that kind of defeat the purpose of the calling convention? (A function designator decays into a function pointer basically any time you mention it.)

> This commit introduces attribute bpf_fastcall to declare BPF functions that do not clobber some of the caller saved registers (R0-R5).

If the attribute can be dropped, then the caller side has to assume the caller-saved registers are still going to be clobbered even in the presence of the attribute, so it always has to save and restore those registers, doesn't it?

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