If you disallow recursion, or put an upper bound on recursion depth, you can statically allocate all "stack based" objects at compile time. Modula I did this, allowing multithreading on machines which did not have enough memory to allow stack growth. Statically analyzing worst case stack depth is still a thing in real time control.
Not clear that this would speed things up much today.
It's too constrained to statically-analyze the whole program to determine required stack size. You can't have calls via function pointers (even virtual calls), can't call thirdparty code without sources available, can't call any code from a shared library (since analyzing it is impossible). This may work only in very constrained environments, like in embedded world.
Mostly.
Analyzing a shared library is possible. All you need is call graph and stack depth.
If function pointers are type constrained, the set of callable functions is finite.
> Not clear that this would speed things up much today.
It would likely slow things down, actually.
One advantage that a stack has is that the stack memory is "hot"--it is very likely in cache due to the fact that it is all right next to one another and used over and over and over. Statically allocated memory, by contrast, has no such guarantee and every function call is likely to be "cold" and need to pull in the cache line with its static variables.
I think you would also need to ban threading and reentrancy (from signals)? Also, if you had function pointers, you would have to pessimize to storing each such function's stack memory separately I think (since the compiler wouldn't be able to figure out the call graph, in general)
Not clear that this would speed things up much today.