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

[via llvm-commits]

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 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.

> And why would it not be named __attribute__((fastcall)) when targeting BPF

I wanted to avoid potential confusion, as `bpf_fastcall` operates in a manner completely different from what `fastcall` for x86 does (first two parameters in `ecx`, `edx`, other parameters on stack).

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