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

[Dmitry Antipov]

On 09/03/2014 06:39 PM, Paul Eggert wrote:

> 3.  It's often better (i.e., faster and/or less memory-intensive) to use a 
> block-scope object,
> which is reclaimed on block exit rather than function exit.  This suggests that 
> we should have
> two forms of cons stack allocation, one block-scope and one function-scope, 
> depending on the
> lifetime that the caller wants.  For a block-scope cons we can use a C99-style 
> compound literal,
> which (unlike alloca) would be safe as an expression.  (We're assuming C99 in 
> the trunk now.)

OK. So, for the simplest object (cons) we can have:

1) Function-scoped version using alloca (assuming statement expressions):

#define alloca_cons(head, tail)                         \
  ({ struct Lisp_Cons *_c = alloca (sizeof *_c);        \
     eassert (pointer_valid_for_lisp_object (_c));      \
     _c->car = (head), _c->u.cdr = (tail);              \
     make_lisp_ptr (_c, Lisp_Cons); })

2) Block-scoped version using implicit stack allocation (assuming statement 
expressions):

#define scoped_cons(head, tail)                 \
  ({ struct Lisp_Cons alignas (GCALIGNMENT) _c; \
     _c.car = (head), _c.u.cdr = (tail);        \
     make_lisp_ptr (&_c, Lisp_Cons); })

3) Block-scoped version assuming no statement expression but compound literals:

#define scoped_cons_2(head, tail)                                       \
  make_lisp_ptr (&((struct Lisp_Cons) { head, { tail } }), Lisp_Cons)

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?

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

Dmitry