Re: [PATCH] Use malloca instead alloca

[Rich Felker <dalias at aerifal dot cx>]

On Sat, Jan 12, 2013 at 05:18:25PM +0100, OndÅej BÃlka wrote:
> On Fri, Jan 11, 2013 at 08:34:42AM -0500, Rich Felker wrote:
> > 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.
> There are two separate issues. First is gcc does not optimize alloca
> well so type[constant] is faster than alloca(constant). This is bug in
> gcc and can be fixed.

No, this _cannot_ be fixed. If any non-static-sized objects exist in
the stack frame, then local variables cannot be addressed sp-relative.
Instead, they need a frame pointer (whether you call it a frame
pointer or not, and whether you use a register for it or a slot on the
stack, it's a frame pointer), and that's fundamentally more expensive.

> Or if speed is such issue you can allocate by
> ({ char buf[128]; buf;})

This has exactly the same issue if the amount to be allocated cannot
be determined statically (at compile time); it precludes sp-relative
addressing.

> Second is freeing. 
> Your aproach (ptr!=fixed_buf) adds mainteinance burden, register
> pressure and is slower than having linked list of malloced arrays and
> testing if(list) free_all(list).

If you have more than one or two, it's almost surely more than you
should be putting on the stack.

Rich