Re: [PATCH] Use malloca instead alloca

[Rich Felker <dalias at aerifal dot cx>]

On Fri, Jan 11, 2013 at 01:53:00PM +0100, OndÅej BÃlka wrote:
> On Wed, Jan 09, 2013 at 12:43:30PM -0500, Rich Felker wrote:
> > On Wed, Jan 09, 2013 at 05:59:45PM +0100, Florian Weimer wrote:
> > > Anyway, to clarify, I'm not interested in enabling split stacks per
> > > se.  But the split stack support records the stack boundary in a TLS
> > > variable, and __builtin_alloca could use that to check (reasonably
> > 
> > OK, that makes sense. I still don't think it's useful however because
> > the "use as much as we have available" idiom is broken.
> > 
> > > >Honestly, my recommendation would be to ban use of alloca and VLA
> > > >entirely and replace them by small fixed-size arrays (like 256-1024
> > > >bytes depending on the expected usage), and simply call malloc when
> > > >the need is greater than the fixed size. This makes the free logic
> > > >easy (if (ptr!=fixed_buf) free(ptr);) and reduces the code size and
> > > >improves performance in the common cases (since the compiler can
> > > >generate better, simpler code when it does not need to do the
> > > >frame-pointer-like logic for managing dynamic-size allocations on the
> > > >stack.
> > > 
> 
> Where do you want to place these arrays? 

Wherever the compiler places automatic variables (i.e. in the real
world, on the stack). Of course there is no other option. Why would
you even ask this?

> On stack?     In better case gcc will translate free check into 
>               comparison with frame pointer.
>               In worse case it won't and you have increased register
>               pressure. This makes code slower.
>               Also with recursive functions you allocate more stack that
>               is needed.

I already explained why it makes code smaller and faster. If you don't
believe me, write some test cases.

Rich