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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
