The PAL ABI does not support dynamically allocated stack objects, so
error out if a compiler frontend created them.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
This doesn't make sense. If you can externally set the stack size as was claimed in a previous patch, you support dynamic allocas
If you are referring to D150609, graphics uses indirect calls (under some known circumstances). It doesn’t use or support dynamic allocas.
Due to a bug in the compiler frontend, allocas got shifted into a non-entry block, which segfaulted in combination with D150609, therefore this patch to make sure nobody tries to use them.
The patch to fix the frontend is in https://github.com/GPUOpen-Drivers/llpc/pull/2542 for reference.
This is a bug, not an ABI constraint. Should fix the bug instead of producing an error.
It's also not PAL specific. OpenMP had the same out-of-entry bug before and reported crashes and nobody ever chased them down.
https://godbolt.org/z/x59xjes4s I think the tear down is just totally broken. It looks like only the allocation side was implemented
This is a bug, not an ABI constraint.
Unless the PAL ABI changes, there is no way for the compiler to tell the thing that allocates scratch (=PAL or the driver) that dynamically sized stack objects exist. That’s why I see this as an ABI constraint.
There is also no need for that because (as far as I am aware) no graphics API exposes the ability to create dynamically sized objects on the stack.
(+nhaehnle for more API knowledge, in case I’m forgetting something.)
It looks like only the allocation side was implemented
Interesting. Maybe we should have an unconditional error then :)
If dynamic call stack works then dynamic alloca works. The common property is compile time unknown stack size which is all that matters. The runtime has no reason to know these objects exist
It looks like only the allocation side was implemented
Interesting. Maybe we should have an unconditional error then :)
This isn't special for dynamic stack. We'll have the same problem with variadic calls (which @JonChesterfield is looking into), so we should just fix this to restore the SP from the FP
I tend to agree with Matt here. *Current* graphics APIs don't allow users to write code that uses dynamic allocas, but since the stack size can be set externally there's no fundamental reason why supporting them should be impossible.
What I'd suggest here is that we beef up the llvm-dialects verifier support a little to make it possible to add custom verifier code, and then checking for non-entry allocas could be added to that verifier exclusively in the frontend.
I also don't think fixing this is all *that* hard. It might take an hour or 2 of staring at emitEpilog