This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Use malloca instead alloca
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. Or if speed is such issue you can allocate by
({ char buf[128]; buf;})
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).
See my testcase http://www.kam.mff.cuni.cz/~ondra/alloc_bench.tar.bz2.
that shows that on sandy bridge there are better aproaches.
>
> Rich