GNU bug report logs - #12541
Prefer plain 'static' to 'static inline'.

Previous Next

Full log

Message #17 received at 12541 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 12541 <at> debbugs.gnu.org
Subject: Re: bug#12541: Prefer plain 'static' to 'static inline'.
Date: Sun, 30 Sep 2012 10:58:57 -0700

On 09/30/2012 02:49 AM, Eli Zaretskii wrote:

> Since what version of GCC we can trust that static functions are
> inlined?

Since pretty long ago.  From the online documentation GCC has been
inlining functions not explicitly declared 'inline' since at least GCC
2.95.3, the oldest manual that's at gcc.gnu.org.  (The documentation
talks about C++ functions not C, but the underlying technology applies
to C too, and I'd be surprised if C differed.)

The exact set of functions that are inlined depends on the platform
and compiler options, as well as the compiler version.

> The inline functions in bidi.c _must_ be inlined for performance
> reasons.

Well, as Jason said, 'inline' is just advice and GCC doesn't always
inline them even now.  On my platform (GCC 4.7.2 -O3, x86-64, Fedora
17, trunk bzr 110287) GCC does not always inline 'bidi_char_at_pos':
in a couple of cases the function is only partly inlined.

With the proposed change, the set of functions that are not always
inlined expands to bidi_cache_iterator_state, bidi_char_at_pos, and
bidi_fetch_char, and (if we also include functions that are partially
inlined) bidi_cache_search and bidi_get_type.  This is all with the
same platform as before.

I don't offhand see how this would slow down Emacs significantly,
as these functions are fairly large.  Is there some benchmark I could
try out, to see the performance effects that are of concern here?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.