[clang] [llvm] [BPF] Support Stack Arguments (PR #189060)
via cfe-commits
cfe-commits at lists.llvm.org
Thu Apr 9 21:56:52 PDT 2026
yonghong-song wrote:
> > For store, we could do hit the first store, do adjustment 'r12 += ' then for the rest stores, there is no need for adjustment hit a call. In this case, do 'r12 -= '.
>
> to know 'first store' JIT would need to do data flow analysis, which is not feasible.
>
> > My current thinking is there is no need to do explicit 12 adjustments, e.g., to accommodate with code sequences like the above. Second, for each store for x86, the offset adjustment is done in jit time. So at runtime, we have no overhead at all.
>
> right, no extra overhead is mandatory, but I'm still missing how you think JIT will do the adjustment. Like compute the maximum of all *(r12 - N) = .. insn and use that in the prologue ?
yes. This is what I did in the patch. Compute the number of stack augument consumption for each callee and get the maximum one. And this maximum one is used in jit for stack allocation before the main loop.
> I guess it works, but then this function will reserve more stack then it needs. like foo() { bar(); // with deep callchain
Sadly yes, esp. for deep callchain.
I previously thought about this whether we could allocate stacks based on each callee. And discussed with claude and claude suggests to use the current approach as alternative one (with minimum stack usage) is very complex to implement. Since you are mentioning this again, let me think whether we can find a way with reasonable complexity to implement this.
>
> meh(lots of args); } the space needed to call meh() will be reserved upfront, so unnecessary stack waste while calling bar() ? For JIT to reserve it right before meh() it would need to know 'first store' and then consider all possible combinations of calling meh(). gets tricky.
https://github.com/llvm/llvm-project/pull/189060
More information about the cfe-commits
mailing list