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