Re: Optimisation across source files.

[Braden McDaniel]

On Fri, 04 Apr 2003 21:44:07 +0100, Dr. David Kirkby wrote:

> Hi,
>       I don't know about other programmers, but I tend to put one function
> in each source file. So function foo() goes into foo.c. Looking
> carefully at the documentation for Sun's c compiler, I not that the
> optimiser will only try to inline functions in the same source file,
> so my method of one source function/file, effectively stops the
> optimiser from inlining any functions. However, Sun's compiler has an
> option, -xcrossfile which will attempt to inline functions across
> files. Great one thinks, just add that option.

[snip]

In general, if you want functions inlined in multiple translation units,
the functions should be defined in a header file. Obviously, these
functions must have internal linkage, so you wind up with a "private" (or,
not to be installed) header.

If you have functions with external linkage that you want to be inlined,
then they will need to be in the same file. But it is unusual to want
this. In general, in C, public "functions" that should be inlined get cast
as macros.
 
> Certainly reading the Sun compiler manual has made me re-think my
> practice of putting each function (except very small ones) in their
> own source file. 

The usual recommendation is "one externally linked symbol definition per
translation unit". This is derived from the tendency of linkers to
discriminate per object file rather than per symbol.

(I'll note that I regularly violate this recommendation and define in the
same translation unit closely related things that will invariably be used
together. This practice has the side effect of letting me avoid putting
too much stuff in private headers.)

> It does not seem unreasonable for automake to keep a list of compiler
> options like this (even if there is one per compiler), and if detected
> build the makefile such that changes in any source file cause all
> those files that are every linked with that file to be rebuilt, even
> if their source has not changed.

I think that since there is a mechanism for achieving this that works
reliably across compilers, there isn't a need for automake to support the
compiler-specific mechanism. It sounds to me like this option for the Sun
compiler creates the same coupling that would be present if the
definitions had been in the same translation unit to begin with.

Braden