emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paul Eggert
Subject: Re: Benchmarking temporary Lisp objects [Was: Re: [RFC] temporary Lisp_Strings]
Date: Wed, 03 Sep 2014 07:39:24 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]