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