Hi all!
Now that LLVM has support for a larger attribute set, I think it is a
good idea to add one that stops LLVM from generating segmented stacked
version of a function. While implementing it, I ran into an issue:
Currently, with segmented stacks enabled, LLVM sets the action for
DYNAMIC_STACKALLOC to Custom, and lowers it into native X86 code.
However, if a function has the nosegmentedstack attribute,
DYNAMIC_STACKALLOC will need to be expanded. Is there some idiomatic
way to choose whether a pseudo op is to be lowered or expanded based
on some function attribute?
Thanks!
Hi Sanjoy,
Now that LLVM has support for a larger attribute set, I think it is a
good idea to add one that stops LLVM from generating segmented stacked
version of a function.
why? If some functions have segmented stacks, don't all functions called
by it need segmented stacks too?
Ciao, Duncan.
While implementing it, I ran into an issue:
No, the check for stack usage can be lifted. E.g. if you have the call
graph
A -- B -- C
\- D -/
B can require the stack space for B, D and C and call the non-checking
versions of them.
Joerg
Moreover, some frontends might want to implement coroutines using
segmented stacks but use a regular thread stack for, well, regular
threads.
I'm glad to hear this news, Sanjoy. Rust currently generates some functions that run with segmented stacks and some that run on big stacks (for C interop and the main function). When we switch to the C stack we have to reconfigure the stack boundary so it doesn't trip the call to __morestack. It would be cleaner if we could just tell LLVM not to generate the check for these functions.