«

On Tue, 12 Jan 2010 21:44:27 -0600, Stephen Sprunk wrote:

>>> Declaring the function "static" gives the compiler more scope for
>>> optimisation, as it can determine exhaustively the contexts in which the
>>> function may be called.
>>
>> This could allow it to take shortcuts on the calling conventions,
>
> Interesting. For instance, a compiler for x86 might decide to forgo the
> usual stack-based calling convention and use a register-based one, which
> would be faster (assuming the number of arguments is reasonable). It
> might also allow the compiler to skip saving some registers in the
> calling function if it knows that the called function won't modify them.
>
> However, does any compiler in the wild actually do this?

Consider the case where the function is inlined more than once, then
common subexpression elimination moves (most of) the inlined code into a
separate subroutine. If the function is static, and all calls have been
inlined, the "real" function definition will be elided.

The effect is the same as implementing the function with a custom calling
convention.

Nobody wrote:
> On Tue, 12 Jan 2010 21:44:27 -0600, Stephen Sprunk wrote:
>
>>>> Declaring the function "static" gives the compiler more scope for
>>>> optimisation, as it can determine exhaustively the contexts in which the
>>>> function may be called.
>>> This could allow it to take shortcuts on the calling conventions,
>> Interesting. For instance, a compiler for x86 might decide to forgo the
>> usual stack-based calling convention and use a register-based one, which
>> would be faster (assuming the number of arguments is reasonable). It
>> might also allow the compiler to skip saving some registers in the
>> calling function if it knows that the called function won't modify them.
>>
>> However, does any compiler in the wild actually do this?
>
> Consider the case where the function is inlined more than once, then
> common subexpression elimination moves (most of) the inlined code into a
> separate subroutine. If the function is static, and all calls have been
> inlined, the "real" function definition will be elided.

If and only if the function's address is not stored in a pointer (which
applies to my earlier comments too).

> The effect is the same as implementing the function with a custom calling
> convention.

It can be, but not always.

One reason you might get different (faster) calling conventions is if
there is an API which specifies one set of conventions (for flexibility)
but something else is faster on modern hardware. If the function is
static and no pointers to it exist, then the compiler knows it is safe
to use the faster calling conventions.

A reason a static function might be inlined when a non-static function
is not is that the balance on code size moves. If it is static and no
pointer is taken, then if all calls are inlined and the original
eliminated it has not inflated code size by as much as inlining it *and*
keeping the original. This is especially relevant if the function is
only called a small number of times (the extreme case being a function
called exactly once).

So I always declare and define functions as static unless I explicitly
need them to be externally visible. Always give the compiler all the
information you can, it might help it make the best decision...
--
Flash Gordon

wrote:

> Richard Bos <> wrote:
> >
> > Address _could_ be a reason, but I cannot find anything in the Standard
> > which demands that different functions have addresses that compare
> > differently. Nor, for that matter, can I find an explicit, blanket
> > demand that all objects' addresses must differ.
>
> 6.5.9p6:
>
> Two pointers compare equal if and only if both are null
> pointers, both are pointers to the same object (including a
> pointer to an object and a subobject at its beginning) or
> function...
>
> Different objects are not "the same object", nor are different functions
> "the same function".

That has not stopped implementation writers from equalising pointers to
string literals. In the source code, these are definitely different
objects, but since a program can only discover the difference by
invoking undefined behaviour, they are allowed to be "the same object"
for pointer purposes. Unless you're telling us that this _very_ common
optimisation is illegal, I don't see why the same thing should not be
allowed for functions for which the same proviso holds.

Richard

(Richard Bos) writes:
> wrote:
>> Richard Bos <> wrote:
>> >
>> > Address _could_ be a reason, but I cannot find anything in the Standard
>> > which demands that different functions have addresses that compare
>> > differently. Nor, for that matter, can I find an explicit, blanket
>> > demand that all objects' addresses must differ.
>>
>> 6.5.9p6:
>>
>> Two pointers compare equal if and only if both are null
>> pointers, both are pointers to the same object (including a
>> pointer to an object and a subobject at its beginning) or
>> function...
>>
>> Different objects are not "the same object", nor are different functions
>> "the same function".
>
> That has not stopped implementation writers from equalising pointers to
> string literals. In the source code, these are definitely different
> objects, but since a program can only discover the difference by
> invoking undefined behaviour, they are allowed to be "the same object"
> for pointer purposes. Unless you're telling us that this _very_ common
> optimisation is illegal, I don't see why the same thing should not be
> allowed for functions for which the same proviso holds.

There are no objects in my source code; objects exist only during
program execution.

The object in question is the "array of static storage duration"
mentioned in C99 6.4.5p5. The standard explicitly allows two string
literals to refer to the same object in C99 6.4.5p6:

It is unspecified whether these arrays are distinct provided their
elements have the appropriate values. If the program attempts to
modify such an array, the behavior is undefined.

As for memcpy and memmove possibly having the same address, I can
imagine a program storing the address of a standard function and later
making some decision based on which standard function the address
points to. I have difficulty imagining *good* code doing something
like this, but it isn't the standard's job to impose good coding
practices.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"