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

[Dmitry Antipov <dmantipov@yandex.ru>]

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