At -O2 and -O3 levels of
optimization, or when --autoline is specified,
the compiler can automatically inline functions if it is practical
and possible to do so, even if the functions are not declared as __inline or inline.
This works best for static functions, because if all use of a static function
can be inlined, no out-of-line copy is required. Unless a function
is explicitly declared as static (or __inline),
the compiler has to retain the out-of-line version of it in the
object file in case it is called from some other module.
It is best to mark all non-inline functions as static if they
are not used outside the translation unit where they are defined
(a translation unit being the preprocessed output of a source file
together with all of the headers and source files included as a
result of the #include directive). Typically, you do
not want to place definitions of non-inline functions in header
files.
If you fail to declare functions that are never called from
outside a module as static, code can be adversely affected.
In particular, you might have:
A larger code size, because out-of-line
versions of functions are retained in the image.
When a function is automatically inlined, both the in-line
version and an out-of-line version of the function
might end up in the final image, unless the function is declared
as static. This might increase code size.
An unnecessarily complicated debug view, because
there are both inline versions and out-of-line versions of functions
to display.
Retaining both inline and out-of-line copies of a function
in code can sometimes be confusing when setting breakpoints or single-stepping
in a debug view. The debugger has to display both in-line and out-of-line
versions in its interleaved source view so that you can see what
is happening when stepping through either the in-line or out-of-line
version.
Because of these problems, declare non-inline functions as static when
you are sure that they can never be called from another module.
This site uses cookies to store information on your computer. By continuing to use our site, you consent to our cookies.
ARM websites use two types of cookie: (1) those that enable the site to function and perform as required; and (2) analytical cookies which anonymously track visitors only while using the site. If you are not happy with this use of these cookies please review our Privacy Policy to learn how they can be disabled. By disabling cookies some features of the site will not work.