From: Paul Eggert <eggert@cs.ucla.edu>
To: Dmitry Antipov <dmantipov@yandex.ru>,
Emacs development discussions <emacs-devel@gnu.org>
Subject: Re: Benchmarking temporary Lisp objects [Was: Re: [RFC] temporary Lisp_Strings]
Date: Wed, 03 Sep 2014 07:39:24 -0700 [thread overview]
Message-ID: <5407281C.3090302@cs.ucla.edu> (raw)
In-Reply-To: <5406EC21.4060200@yandex.ru>
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.
next prev parent reply other threads:[~2014-09-03 14:39 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-02 12:55 [RFC] temporary Lisp_Strings Dmitry Antipov
2014-09-02 13:21 ` Andreas Schwab
2014-09-02 13:47 ` Dmitry Antipov
2014-09-02 14:14 ` Andreas Schwab
2014-09-02 15:00 ` Eli Zaretskii
2014-09-02 14:00 ` Stefan Monnier
2014-09-02 15:13 ` Dmitry Antipov
2014-09-02 17:32 ` Stefan Monnier
2014-09-03 10:23 ` Benchmarking temporary Lisp objects [Was: Re: [RFC] temporary Lisp_Strings] Dmitry Antipov
2014-09-03 13:14 ` Stefan Monnier
2014-09-03 14:39 ` Paul Eggert [this message]
2014-09-03 15:39 ` Dmitry Antipov
2014-09-03 16:42 ` Paul Eggert
2014-09-03 17:47 ` Stefan Monnier
2014-09-03 18:00 ` Paul Eggert
2014-09-04 4:59 ` Dmitry Antipov
2014-09-04 5:13 ` Paul Eggert
2014-09-04 5:51 ` Dmitry Antipov
2014-09-04 6:45 ` Paul Eggert
2014-09-04 13:11 ` Stefan Monnier
2014-09-04 13:37 ` Dmitry Antipov
2014-09-04 14:46 ` Dmitry Antipov
2014-09-04 16:03 ` Paul Eggert
2014-09-05 4:00 ` Dmitry Antipov
2014-09-05 4:24 ` Stefan Monnier
2014-09-05 9:28 ` Dmitry Antipov
2014-09-05 7:15 ` Paul Eggert
2014-09-05 9:16 ` Dmitry Antipov
2014-09-05 14:35 ` Paul Eggert
2014-09-05 15:35 ` Stefan Monnier
2014-09-08 10:33 ` Dmitry Antipov
2014-09-08 12:01 ` Dmitry Antipov
2014-09-08 13:30 ` Stefan Monnier
2014-09-08 12:44 ` Stefan Monnier
2014-09-08 13:30 ` Stefan Monnier
2014-09-02 14:37 ` [RFC] temporary Lisp_Strings Paul Eggert
2014-09-02 15:24 ` Dmitry Antipov
2014-09-02 15:28 ` Dmitry Antipov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5407281C.3090302@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=dmantipov@yandex.ru \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.