Some optimization thoughts (and thanks!)

[Jean Francois Martinez]

Carlo Wood a écrit :

> On Tue, May 01, 2001 at 11:08:39AM -0400, At150bogomips@aol.com wrote:
> > Here are some optimization suggestions:
> >
> > * Inlining of all functions with a single caller: This would presumably
> >   be done after short-function inlining (to allow wrapper functions to
> >   be inlined into their callers, such wrappers are likely have condition
> >   checks and such which can be simplified if inlined into the more basic
> >   caller; but if the function that a wrapper calls is inlined first, the
> >   resulting function may be too large to inline for multiple basic
> >   callers).  This removes the performance penalty of breaking code into
> >   graspable portions.  Unlike regular inlining, this reduces code size
> >   (by removing call/return overhead).  This should not be that difficult
> >   to implement, nor add much to compile time, particularly if the
> >   call-tree for a program is retained between compilings and partially
> >   updated after source modification.
>
> The compiler can't know how often a function is called, only the linker
> can.  This would be possible for static functions, but I'd be highly
> surpriced when static functions with one caller aren't already inlined :/
>

The linker knows if a function is called from many places,  it does not know
if
a function is called often.  Think in a cleaning function who
is called just before exit after we detected something was wrong.   Only the
programmer knows if a function will be called often.  And that is why when
the
progtrammer inlined functions by hand then using -O3 instead of -O2 will just

make the programmer bigger (compiler inlines some "nearly dead functions")
and
slower since there is no speed benefit from inlining nearly dead functions
and you
still pay a penalty for additional TLB and cache misses.


                                                JFM


> [...]
> > (I am disappointed that gcc does not surpass all other compilers in
> > optimization--gcc should be the best in everything (portability,
> > optimization, compile speed, standards conformance, etc.).  It is
> > particularly disappointing that gcc seems to miss some common
> > optimizations (e.g., loop arrangement to optimize memory access
> > patterns).  I am, of course, very happy that gcc is Free--a compiler is
> > a system component even if some vendors do not think so.)
>
> I am not a developer of gcc, just a beta tester (or rather someone who
> needs the compiler to work for his own work and therefore reports all
> bugs he runs into) - but I understood that the priority of version 3.0
> is to make the compiler 100% conforming the new standard; only after
> it compiles everything attention will be turned to optimisation issues.
> There are still many years to go :)
>
> --
> Carlo Wood <carlo@alinoe.com>