Displaying 3 results from an estimated 3 matches for "b5220b90".
2018 May 11
0
best way to represent function call with new stack in LLVM IR?
On 2018-05-11 02:28, Andrew Kelley via llvm-dev wrote:
> In the Zig frontend, we know at compile-time the entire call graph.
> This means we know stack size for all functions and therefore the
> upper bound stack usage.
>
> [snip]
> 1. Is there a way to accomplish this with existing LLVM API?
You should use the @llvm.stacksave and @llvm.stackrestore intrinsic.
It is only legal
2018 May 11
1
best way to represent function call with new stack in LLVM IR?
...ncerning - do the other architectures not allow
modification of the stack register? Or is this a TODO item in LLVM?
>
> --
> whitequark
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180510/b5220b90/attachment.html>
2018 May 11
2
best way to represent function call with new stack in LLVM IR?
In the Zig frontend, we know at compile-time the entire call graph. This
means we know stack size for all functions and therefore the upper bound
stack usage.
Recursive calls can have a runtime-decided stack usage, and therefore I am
adding a frontend feature that will heap-allocate memory to use for some
function calls.
The idea is that recursion adds cycles to the call graph, and we know at