Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

[Jan Hubicka <hubicka at ucw dot cz>]

> On 07/20/16 20:08, Richard Biener wrote:
> > On July 20, 2016 6:54:48 PM GMT+02:00, Bernd Edlinger <bernd.edlinger@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?

I just looked up the original patch introducing MAY_BE_ALLOCA
https://gcc.gnu.org/ml/gcc-patches/2000-03/msg00998.html
I did not introduce the flag and it was there for ages (I just came with
ECF_*).  The reason for it back then was only to prevent pending stack
adjustements before call to alloca. It is not completely clear to me why it is
needed - if alloca is bulitin it will do pending adjustments. There used to be
library implementation of alloca which did malloc and then gabrage collected
based on stack pointer. For that you need no special handling.

Unrolling is safe WRT alloca (because it depends on how many the function is
invoked). I added the logic to prevent inlining long time ago because otherwise
gcc benchmark from SPEC exploded in stack usage.
It is ages on my TODO to remove it and instead save/restore stack pointer around
inlined functions which does alloca.

Not fully relevant for this thread, just my 2 cents ;)
Honza
> 
> 
> Bernd.