3 ms·
AFAIK Zig doesn't have a way to calculate maximum stack usage at build time. But perhaps this could be done in a language-independent way, in LLVM. That would p
by mwcampbell 7y ago
AFAIK Zig doesn't have a way to calculate maximum stack usage at build time. But perhaps this could be done in a language-independent way, in LLVM. That would probably be better anyway, since to really do it well, you'd have to do whole-program analysis, including calls between Zig and C.
- snops 7y agoInteresting, GCC has '-fstack-usage' to output the stack usage of each function into .su files, I didn't realise LLVM was lacking this feature. There is a tool in rust[1] I just found that makes LLVM emit this information for rust code, but it stores it within[2] the .stack_sizes section in the emitted .elf instead. Possibly a similar trick could be added to Zig [1] https://github.com/japaric/stack-sizes https://github.com/japaric/stack-sizes [2] https://llvm.org/docs/CodeGenerator.html#emitting-function-stack-size-information https://llvm.org/docs/CodeGenerator.html#emitting-function-s...
- mwcampbell 7y agoI was referring to T1's ability to guarantee a particular stack size for the whole program (if I understand correctly), not individual functions.
- AndyKelley 7y agoit's been planned since the beginning: https://github.com/ziglang/zig/issues/157 https://github.com/ziglang/zig/issues/157 https://github.com/ziglang/zig/issues/1639 https://github.com/ziglang/zig/issues/1639 also I figured out how to have safe recursion, taking advantage of the stackless coroutines: https://github.com/ziglang/zig/issues/1006 https://github.com/ziglang/zig/issues/1006 this is relatively straightforward to solve in a non-llvm backend. The LLVM abstraction gets leaky fast when you try to tackle this problem.