Re: Benchmarking temporary Lisp objects [Was: Re: [RFC] temporary Lisp_Strings]

[Paul Eggert]

Dmitry Antipov wrote:

> 1) Function-scoped version using alloca (assuming statement expressions):
> ...
> 2) Block-scoped version using implicit stack allocation (assuming
> statement expressions):
> ...
> 3) Block-scoped version assuming no statement expression but compound
> literals:
> ...
> If we have 2), why we need 1) at all? 2) in a top-level function scope
> is an equivalent to 1), isn't it?

Correct.  We'd need (1) e.g. to build up a list in a loop, and have the 
list survive until function exit.  But on further thought this is 
probably a dangerous feature, since it'll be too tempting to write 
unbounded loops.  So let's not do (1).

> In 3), how we can be sure that Lisp_Cons is properly aligned on stack?

For GCC, we can define struct Lisp_Cons via 'struct __attribute__ 
((aligned (GCALIGNMENT))) Lisp_Cons { ... };'.  For compilers that don't 
support this syntax we can align the struct by hand, by using a 
character-array compound literal that's a bit too large, aligning the 
resulting pointer by hand, and then using the aligned pointer.