Are static functions better optimized by compilers?

[llothar]

I'm using SmallEiffel - which is more or less a huge preprocessor -
for C. It has the option to compile the whole Eiffel program into one
huge C file but doesn't add a static declaration to the functions.

I wonder if there are some clever optimizing compilers that do more
magic (for example inlining) of static functions.

It's not much time to patch the eiffel compiler, but if it is useless
there are other things to waste time.

 

[Chris Torek]

I'm using SmallEiffel - which is more or less a huge preprocessor -
for C. It has the option to compile the whole Eiffel program into one
huge C file but doesn't add a static declaration to the functions.

I wonder if there are some clever optimizing compilers that do more
magic (for example inlining) of static functions.

The answer is, as usual for most of these sorts of things, both
no and yes.

I know of at least two compilers that will in-line-expand function
calls (whether static or not) in some cases. If the function *is*
static, and all calls to it are expanded in line (or there were
none in the first place), at least one of these compilers will omit
code for the function (since it is now neither called nor call-able).
If it is not static, this compiler will leave it in. So, for
instance:

#include <stdlib.h>

#ifdef DO_USE_STATIC
static
#endif
int zero(void) { return 0; }

int main(void) { exit(zero()); }

will compile to a smaller executable when you add -DDO_USE_STATIC
to the compilation command.

I know of other compilers where "static" has no effect at all on
code size or speed (just symbol visibility).

It's not much time to patch the eiffel compiler, but if it is useless
there are other things to waste time.

At least one of those compilers will only do in-line expansion if
the definition of the function occurs (lexically) before the call
in question (and even then only if the function is "small" and
meets other suitability constraints).

 

[websnarf]

I'm using SmallEiffel - which is more or less a huge preprocessor -
for C. It has the option to compile the whole Eiffel program into one
huge C file but doesn't add a static declaration to the functions.

I wonder if there are some clever optimizing compilers that do more
magic (for example inlining) of static functions.

It's not much time to patch the eiffel compiler, but if it is useless
there are other things to waste time.

It depends on the C compiler. If the compiler is able to do "whole
program compilation", on the Intel compiler it will make no
difference; it will treat the functions as if they were declared
static, and leveral all possible optimization opportunities. I think
the latest Microsoft compilers may also be able to do this. Older
compilers, or compiler forced to emit individualized per-module object
files that are then linked seperately will produce less efficient
results, if they leverage static function optimizations.

Usually the big deal with static functions is that the compiler can
violate the "ABI" (and thus sometimes remove the need to save and
restore registers from the call site to reuse them as parameters to
the leaf function) or treat the function as if it were "inline". It
can also perform really aggressive kinds of optimizations like cloning
and parameter propogation, and drop any of the unused clones
(typically including the bare function.)

 

[Eric Sosman]

llothar wrote On 03/15/07 04:25,:

I'm using SmallEiffel - which is more or less a huge preprocessor -
for C. It has the option to compile the whole Eiffel program into one
huge C file but doesn't add a static declaration to the functions.

I wonder if there are some clever optimizing compilers that do more
magic (for example inlining) of static functions.

It's not much time to patch the eiffel compiler, but if it is useless
there are other things to waste time.

The optimization may or may not be better, but at least
the information available to the optimizer is more complete
for a static function than for an externally-linked function.
If the optimizer can "see" all of the calls to the function,
it may be able to take actions that would not be possible if
the function could be called from unknown, separately-compiled
modules that may not even have been written yet.

The pre-Standard VAXC implementation took advantage of
the extra optimization opportunities for static functions.
Its <ctype.h> header contained static definitions of all the
isxxx() and toxxx() functions, not the more usual external
declarations plus masking macros. In the course of optimizing,
the compiler would simply discard any static functions that
weren't used. If you included <ctype.h> you'd get source code
for all the functions, but if you used only isdigit() there
would be no generated code for isalpha() and tolower() and
the rest. I think VAXC would also in-line sufficiently simple
static functions, like those of <ctype.h>, making the masking
macros unnecessary.

The technique had some odd consequences: for example, two
different modules could create function pointers aimed at
isalpha(), and the pointers would compare unequal. I do not
know whether that was a violation of the Standard -- but, as
I mentioned, VAXC was pre-Standard anyhow, and disagreed with
the Standard in other ways, too.