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

[Paul Eggert <eggert@cs.ucla.edu>]

Dmitry Antipov wrote:
> 1) Should alloca_vector fallback to Fmake_vector for large vectors?

Of course.  It should be like SAFE_NALLOCA.

> 2) Is there a way to rewrite alloca_xxx macros to avoid statement
>     expressions?  IIUC this is not portable beyond gcc and compilers
>     that mimics it (clang, Intel's icc).

Some thoughts:

1.  It's OK to use statement expressions on compilers that support them, 
and fall back on slower technology on those that don't.

2.  That being said, the GNU alloca documentation says "Do not use 
'alloca' inside the arguments of a function call", i.e., that code must 
not do foo (alloca (n)), but instead must do (p = alloca (n), foo (p)). 
  So it's not clear that trying to do these macros as expressions will work.

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.)  For a block-scope 
vector, if __STDC_NO_VLA__ is not defined we can declare a 
variable-length array, otherwise we can fall back on alloca and/or malloc.

4.  Looking through the Emacs code now, I see that it's not disciplined 
about using SAFE_ALLOCA/SAFE_NALLOCA/etc. for unbounded arrays on the 
stack.  I'll look into cleaning this up.