On 07/20/2016 12:30 PM, Bernd Edlinger wrote:
On 07/20/16 20:08, Richard Biener wrote:
On July 20, 2016 6:54:48 PM GMT+02:00, Bernd Edlinger
<bernd.edlin...@hotmail.de> wrote:
Yes. That is another interesting observation. I think, originally this
flag was introduced by Jan Hubicka, and should mean, "it may be alloca
or a weak alias to alloca or maybe even something different".
But some of the later optimizations use it in a way as if it meant
"it must be alloca". However I have not been able to come up with
a test case that makes this assumption false, but I probably just
did not try hard enough.
But I think that alloca just should not be recognized by name any
more.
It was introduced to mark calls that should not be duplicated by inlining or
unrolling to avoid increasing stack usage too much. Sth worthwhile to keep
even with -ffreestanding.
Richard.
Apparently the MAY_BE_ALLOCA issue is worse than I ever thought...
But I could not imagine that alloca can be anything else than a
built-in.
Is there any implementation where alloca is like an ordinary function
call?
I mean, does something like a function that allocates n bytes
from the caller's stack frame work at all with any calling convention?
IIRC alloca was actually a normal call on some systems. It'd use the
current value of hte stack pointer to record the depth of the call chain
and the objects allocated at that particular depth. Calls to alloca
would walk those chains to automatically deallocate objects that had
been allocated in frames that had been subsequently popped.
Of course it was a heuristic and if you used alloca in fun1, then
returned from fun1 and called fun2, then used alloca in fun2, you might
expect objects allocated in fun1 to go away, but that didn't always
happen (consider if fun1 & fun2 have the same stack size :(...
I don't know if any systems still implement alloca this way, but it was
certainly was implemented as a normal call on some systems in the past.
jeff
